WO2020004486A1 - オンラインサービス提供システム、アプリケーションプログラム - Google Patents

オンラインサービス提供システム、アプリケーションプログラム Download PDF

Info

Publication number
WO2020004486A1
WO2020004486A1 PCT/JP2019/025434 JP2019025434W WO2020004486A1 WO 2020004486 A1 WO2020004486 A1 WO 2020004486A1 JP 2019025434 W JP2019025434 W JP 2019025434W WO 2020004486 A1 WO2020004486 A1 WO 2020004486A1
Authority
WO
WIPO (PCT)
Prior art keywords
user
service providing
server
procedure
user device
Prior art date
Application number
PCT/JP2019/025434
Other languages
English (en)
French (fr)
Inventor
尚久 福田
グレッグ ダイクマン
裕昭 横山
渋谷　靖
昌孝 林
Original Assignee
日本通信株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 日本通信株式会社 filed Critical 日本通信株式会社
Priority to JP2020527589A priority Critical patent/JP7469756B2/ja
Priority to US17/255,455 priority patent/US11617084B2/en
Priority to EP19825083.9A priority patent/EP3817278A4/en
Publication of WO2020004486A1 publication Critical patent/WO2020004486A1/ja
Priority to JP2023222237A priority patent/JP2024024011A/ja

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/40—Security arrangements using identity modules
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3226—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using a predetermined code, e.g. password, passphrase or PIN
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/322—Aspects of commerce using mobile devices [M-devices]
    • G06Q20/3221—Access to banking information through M-devices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/322—Aspects of commerce using mobile devices [M-devices]
    • G06Q20/3223—Realising banking transactions through M-devices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/322—Aspects of commerce using mobile devices [M-devices]
    • G06Q20/3229—Use of the SIM of a M-device as secure element
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/326—Payment applications installed on the mobile devices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/326—Payment applications installed on the mobile devices
    • G06Q20/3263—Payment applications installed on the mobile devices characterised by activation or deactivation of payment capabilities
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/341—Active cards, i.e. cards including their own processing means, e.g. including an IC or chip
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/355—Personalisation of cards for use
    • G06Q20/3552—Downloading or loading of personalisation data
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/357—Cards having a plurality of specified features
    • G06Q20/3574—Multiple applications on card
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3823—Payment protocols; Details thereof insuring higher security of transaction combining multiple encryption tools for a transaction
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • G06Q20/4014—Identity check for transactions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0442—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply asymmetric encryption, i.e. different keys for encryption and decryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0853—Network architectures or network communication protocols for network security for authentication of entities using an additional device, e.g. smartcard, SIM or a different communication terminal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0861—Network architectures or network communication protocols for network security for authentication of entities using biometrical features, e.g. fingerprint, retina-scan
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H04L63/126—Applying verification of the received information the source of the received data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/0825—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using asymmetric-key encryption or public key infrastructure [PKI], e.g. key signature or public key certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/321—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/03—Protecting confidentiality, e.g. by encryption
    • H04W12/033—Protecting confidentiality, e.g. by encryption of the user plane, e.g. user's traffic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/03—Protecting confidentiality, e.g. by encryption
    • H04W12/037—Protecting confidentiality, e.g. by encryption of the control plane, e.g. signalling traffic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/04—Key management, e.g. using generic bootstrapping architecture [GBA]
    • H04W12/041—Key generation or derivation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/04—Key management, e.g. using generic bootstrapping architecture [GBA]
    • H04W12/047—Key management, e.g. using generic bootstrapping architecture [GBA] without using a trusted network node as an anchor
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H04W12/069—Authentication using certificates or pre-shared keys
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/10—Integrity
    • H04W12/108—Source integrity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/60—Context-dependent security
    • H04W12/69—Identity-dependent
    • H04W12/72—Subscriber identity

Definitions

  • the present invention relates to a technique for improving security when using an online service from a portable device.
  • MITM man-in-the-middle attacks
  • MITM attacks use malware and fake sites to hijack communications between online banking users and financial institutions (falsify communications), and illegally transfer money without being noticed by both users and financial institutions.
  • This is an attack method that performs processing and the like.
  • MITB Man ⁇ In ⁇ The ⁇ Browser
  • MITM is also a kind of MITM.
  • remittance processing using the ATM network has been performed for a long time, the risk of cyber attacks has been extremely low because a dedicated line was conventionally used.
  • online services using an open network such as the Internet are exposed to various threats such as an MITM attack.
  • a method using a one-time password issuer is widely used as a security measure. This is done by distributing a one-time password issuer to service users in advance and using the one-time password generated and displayed by the one-time password issuer when logging in to the service or performing remittance processing. This is a method of performing authentication (see Patent Document 1). However, this method has no effect on MITM attacks.
  • a MITB attack which is a type of MITM attack, a user inputs authentication information such as a login ID and a one-time password by malware or a fake site, and the user is spoofed using the authentication information as it is. is there.
  • Transaction authentication is generally realized by a combination of encryption (electronic signature) of a transaction between a user and a server, and confirmation of transaction contents using a session on a path different from a browser.
  • a dedicated device called a token is often used (see Patent Document 2).
  • each financial institution is opening API (Application @ Programming @ Interface) to agents such as account settlement and electronic remittance for electronic payments. I'm advancing. Therefore, in the future, not only the security between the financial institution and the user but also the security between the financial institution (online service provider), the electronic payment agency (intermediate service provider), and the user Need to secure.
  • API Application @ Programming @ Interface
  • the present invention has been made in view of the above circumstances, and has as its object to provide a new security technology capable of realizing the use of a secure service without impairing the convenience of mobile.
  • a further object of the present invention is to provide a new security technique that can ensure a high level of security between an online service provider, an intermediate service provider, and a user.
  • An online service providing system that provides a mechanism that can be safely used from a portable device through an intermediate service provided by a different person from the service provider, the online service provided by the service provider, A service providing server that provides the registered user with the online service through the Internet; An intermediate server that provides the user with the intermediate service through the Internet; An IC chip provided on a user device which is a portable device possessed by the user; An application program that is executed by a main processor included in the user device and causes the user device to function as a terminal for using the intermediate service,
  • the IC chip comprises: At least, personal information used for user authentication to confirm the legitimacy of the person using the user device, a secret key of the user, a public key of the user paired with the secret key, and the public key
  • a memory for temporarily storing an electronic certificate of the user, including: At least, an authentication function for performing the user authentication by comparing information provided from the application program with the personal information, and an electronic signature function for performing an electronic signature using the secret key on data provided from the application program
  • the intermediate server User information storage means for storing an electronic certificate of the user as information on the user,
  • the login request is received from the user device, the validity of the login request is confirmed by verifying the electronic signature included in the login request using the electronic certificate of the user, and the login request is Control means for permitting use of the intermediate service from the user device when it is confirmed as legitimate, and transmitting an access request including the electronic signature included in the login request to the service providing server via the Internet; and , Has,
  • the service providing server, User information storage means for storing an electronic certificate of the user as information on the user When the access request is received from the intermediate server, the access request is checked for validity by verifying the electronic signature included in the access request using the electronic certificate of the user, and the access request is Access control means for permitting the intermediate server to use the online service on behalf of the user when it is confirmed as legitimate;
  • An online service providing system is provided.
  • a second aspect of the present invention provides An intermediate service that is executed by a main processor of a user device that is a portable device possessed by a user and provides the user device with an online service provided by a service providing server through the Internet by an intermediate server different from the service providing server.
  • An application program that functions as a terminal for use through The user equipment includes: At least, personal information used for user authentication to confirm the legitimacy of the person using the user device, a secret key of the user, a public key of the user paired with the secret key, and the public key
  • a memory for temporarily storing an electronic certificate of the user, including: At least, an authentication function for performing the user authentication by comparing information provided from the application program with the personal information, and an electronic signature function for performing an electronic signature using the secret key on data provided from the application program
  • the present invention provides a service providing server or an intermediate server, or a portable device including the IC chip and an application program, or an online service providing method including at least a part of the processing, or the IC. It can also be considered as a method for controlling a portable device including at least a part of the processing by the chip and the application program, or a computer-readable storage medium that temporarily stores the application program.
  • the present invention it is possible to provide a new security technology capable of realizing secure service utilization without impairing the convenience of mobile. Further, according to the present invention, it is possible to provide a new security technique capable of ensuring a high level of security among three users, that is, an online service provider, an intermediate service provider, and a user.
  • FIG. 1 is a diagram showing one of the features of the online service providing system according to the present invention.
  • FIG. 2 is a block diagram illustrating a configuration of a service providing server that provides an online service.
  • FIG. 3 is a block diagram showing a configuration of a user device used to use an online service.
  • FIG. 4 is a diagram schematically showing the appearance and mounting form of the SIM card and the IC card.
  • FIG. 5 is a block diagram schematically showing a hardware configuration of the SIM card and the IC card.
  • FIG. 6 is a block diagram schematically illustrating a logical configuration of the user device and the IC card.
  • FIG. 7 is a diagram illustrating an IC card issuance procedure.
  • FIG. 8 is a diagram illustrating an IC card issuance procedure.
  • FIG. 1 is a diagram showing one of the features of the online service providing system according to the present invention.
  • FIG. 2 is a block diagram illustrating a configuration of a service providing server that provides an online service.
  • FIG. 9 is a diagram showing a data structure of the IC card management database.
  • FIG. 10 is a diagram showing a flow of a registration procedure for an intermediate service.
  • FIG. 11 is a diagram showing the flow of the registration procedure for the intermediate service (continuation of FIG. 10).
  • FIG. 12 is an example of a screen displayed on the user device in the registration procedure for the intermediate service.
  • FIG. 13 is a diagram illustrating a flow of login authentication of the intermediate service.
  • FIG. 14 is an example of a screen displayed on the user device in the login authentication of the intermediate service.
  • FIG. 15 is a diagram showing a flow when using the intermediate service.
  • FIG. 16 is an example of a screen displayed on the user device when using the intermediate service.
  • FIG. 16 is an example of a screen displayed on the user device when using the intermediate service.
  • FIG. 17 is a block diagram schematically illustrating a hardware configuration of a user device including a secure element.
  • FIG. 18 is a block diagram schematically illustrating a hardware configuration of a user device including a SIM card.
  • FIG. 19 is a diagram illustrating post-installation of an electronic certificate.
  • FIG. 20 is a diagram illustrating an example of a mechanism for specifying an IC chip used in the user device when performing communication between the user device and the intermediate server or the service providing server.
  • FIG. 21 is a diagram illustrating an example of a mechanism for specifying an IC chip used in the user device when performing communication between the user device and the intermediate server or the service providing server.
  • FIG. 22 is a diagram showing a flow of a registration procedure for an intermediate service.
  • FIG. 23 is a diagram showing a flow of login authentication of the intermediate service.
  • FIG. 24 is a diagram showing a flow when using the intermediate service.
  • FIG. 25 is a diagram showing the flow of the registration procedure for the intermediate service.
  • FIG. 26 is a diagram showing the flow of the registration procedure for the intermediate service.
  • FIG. 27 is a diagram showing a flow of login authentication of the intermediate service.
  • FIG. 28 is a diagram showing a flow when using the intermediate service.
  • FIGS. 29A to 29C are diagrams showing examples of multistage connection of servers.
  • FIG. 30 is a diagram showing the flow of the registration procedure for the intermediate service.
  • FIG. 31 is a diagram showing a flow of login authentication of the intermediate service.
  • FIG. 32 is a diagram showing a flow of login authentication of the intermediate service.
  • FIG. 33 is a diagram showing a flow when using the intermediate service.
  • FIG. 34 is a diagram showing a flow when using the intermediate service.
  • FIG. 1 shows a flow of a procedure content signature (transaction signature) using public key cryptography using an IC card called a sub SIM, which is one of the features of the online service providing system according to the present invention.
  • a service provider is a person who provides an online service through the Internet, and corresponds to, for example, a bank which provides an online banking service.
  • the intermediate service provider is a service provider that provides (intermediates) the online service provided by the service provider (hereinafter, referred to as “intermediate service” or “proxy service”).
  • An agent such as an electronic payment agency that provides a web service such as account management, electronic remittance, and income and expenditure management corresponds to this.
  • An application program (hereinafter, also referred to as “app (APP)”) for using an intermediate service is installed in a user device (such as a smartphone) owned by the user, and an IC card called a sub SIM is mounted.
  • the sub SIM stores a secret key unique to the user.
  • the public key that forms a pair with a private key is subject to the Act on Electronic Signatures and Authentication (Act No. 102 of 2000; hereinafter, referred to as the “Electronic Signature Law”). It is assumed that the certificate has been registered in advance with a certification authority that has been accredited based on the certification, and that the certification authority has issued an electronic certificate.
  • the intermediate server transfers the electronic signature and the procedure message to the server of the online service. Then, the server verifies the digital signature using the corresponding digital certificate, and if it is confirmed that the message is a procedural message sent from a valid user and that the content is not falsified, Execute procedures such as transfer according to the contents of the message.
  • a secret key stored in an IC card called a sub SIM and an encryption function provided by the IC card are used, secure data communication can be realized.
  • This private key has a low risk of leakage, and cannot use the secret key or the encryption function without clearing the PIN code, password, or biometric authentication, thus reducing the risk of unauthorized use by a third party. It can be as small as possible.
  • FIG. 2A is a block diagram illustrating a configuration of the intermediate server.
  • the intermediate server 21 is a server that provides an intermediate service provided by an intermediate service provider through the Internet.
  • the intermediate server 21 will be described using an example of an intermediate service that performs various procedures of an online financial transaction service (so-called online banking) by a financial institution such as a bank.
  • online banking online financial transaction service
  • a financial institution such as a bank
  • the present invention is preferably applicable to all kinds of intermediate services.
  • the intermediate server 21 has, as main functions, a user registration unit 210, a user information storage unit 211, a login control unit 212, and a proxy control unit 213.
  • the user registration unit 210 has a function of performing a new user registration process.
  • the user information storage unit 211 is a database that stores and manages information on registered users.
  • the login control unit 212 has a function of controlling whether or not to use an intermediate service and whether or not to access an online service in response to a login request from a user.
  • the proxy control unit 213 has a function of controlling proxy of a corresponding procedure of the online service in response to a procedure request from a user. Details of these functions and their processing will be described later.
  • the intermediate server 21 can be configured by a general-purpose computer including a CPU (processor), a memory (RAM), a storage (HDD, SSD, etc.), a communication I / F, an input / output device, and the like.
  • a general-purpose computer including a CPU (processor), a memory (RAM), a storage (HDD, SSD, etc.), a communication I / F, an input / output device, and the like.
  • the above-described functions and the processing thereof are realized by expanding a program stored in a storage into a memory and executing the program by a CPU.
  • the intermediate server 21 may be configured by one computer, or may be configured by distributed computing or cloud computing. Further, a dedicated computer may be used instead of a general-purpose computer, or the above-described functions or a part of the processing may be constituted by an ASIC or an FPGA instead of software.
  • FIG. 2B is a block diagram illustrating a configuration of the service providing server.
  • the service providing server 20 is a server that provides an online service (Web service) by a service provider through the Internet.
  • Web service an online service
  • the service providing server 20 will be described by taking an example of an online financial transaction service (so-called online banking) by a financial institution such as a bank.
  • this is merely one application example, and the present invention is applicable to all kinds of services. It is preferably applicable to online services.
  • the service providing server 20 has a user registration unit 200, a user information storage unit 201, an access control unit 202, and a procedure control unit 203 as main functions.
  • the user registration unit 200 has a function of performing a new user registration process.
  • the user information storage unit 201 is a database that stores and manages information on registered users.
  • the access control unit 202 has a function of controlling whether or not to access an online service in response to an access request from the intermediate server 21.
  • the procedure control unit 203 has a function of controlling execution of a corresponding procedure of the online service in response to a procedure request from the intermediate server 21. Details of these functions and their processing will be described later.
  • the service providing server 20 can be configured by, for example, a general-purpose computer including a CPU (processor), a memory (RAM), a storage (HDD, SSD, etc.), a communication I / F, an input / output device, and the like.
  • a general-purpose computer including a CPU (processor), a memory (RAM), a storage (HDD, SSD, etc.), a communication I / F, an input / output device, and the like.
  • the above-described functions and the processing thereof are realized by expanding a program stored in a storage into a memory and executing the program by a CPU.
  • the service providing server 20 may be configured by one computer, or may be configured by distributed computing or cloud computing. Further, a dedicated computer may be used instead of a general-purpose computer, or the above-described functions or a part of the processing may be constituted by an ASIC or an FPGA instead of software.
  • FIG. 3 is a block diagram illustrating a configuration of a portable device (referred to as “user device”) used by a user to use the intermediate service.
  • a smartphone is exemplified as an example of the user device 30, but this is only one application example.
  • the user device 30 has a processor and a memory for executing an application program for using an intermediate service, is equipped with a SIM card (Subscriber Identity Module Card), and can be connected to the Internet. Any device may be used as long as it is an electronic device of.
  • a smartphone for example, a tablet terminal, a mobile PC, a wearable PC, a smart watch, a smart glass, a smart wallet, a portable game machine, and the like can be exemplified.
  • the user device 30 has a CPU (processor) 300, a memory 301, a storage 302, a touch panel display 303, a communication module 304, a power supply 305, a SIM card 306, an IC card 307, and an NFC chip 320 as main hardware resources.
  • the memory 301 is a RAM, and provides a storage area used by the CPU 300 as a working memory.
  • the storage 302 is a non-volatile storage medium for storing application programs and various data, and includes, for example, a built-in EEPROM, a flash memory mounted in a card slot, and the like.
  • the touch panel display 303 is a device that doubles as a display device and an input device.
  • the communication module 304 is a device that performs data communication and voice communication by the user device 30. It is assumed that the communication module 304 according to the present embodiment is compatible with communication using a mobile phone network such as 3G or 4G / LTE, Wi-Fi communication, short-range wireless communication, and the like.
  • the power supply 305 supplies power to the user device 30, and includes a lithium ion battery and a power supply circuit.
  • the SIM card 306 is a contact-type IC card in which subscriber information of communication using a mobile phone network is recorded.
  • the IC card 307 is also a contact-type IC card like the SIM card 306.
  • the IC card 307 is a device additionally attached to the user device 30 to realize secure use of the intermediate service and the online service.
  • the NFC chip 320 is an IC chip that provides an NFC (Near Field Communication) standard short-range wireless communication function and an application using the function.
  • the SIM card 306, the IC card 307, and the NFC chip 320 are configured by different hardware.
  • the SIM card 306 and / or the IC card 307 may have an NFC function.
  • FIG. 4 is a block diagram schematically illustrating the appearance and mounting of the SIM card 306 and the IC card 307
  • FIG. 5 is a block diagram schematically illustrating the hardware configuration of the SIM card 306 and the IC card 307.
  • the SIM card 306 has a structure in which the IC chip 40 is mounted on a resin plate having a width of 15 mm, a height of 12 mm, and a thickness of 0.76 mm.
  • the IC chip 40 has a processor 401, a RAM 402, a nonvolatile memory 403, and eight pins (electrodes) 404.
  • the non-volatile memory 403 stores data such as a unique serial number (ICCID) of the SIM card 306, subscriber identification information (IMSI), and a program executed by the processor 401.
  • the eight pins 404 include a power input terminal, a reset terminal, a clock terminal, a ground terminal, a program voltage input terminal, an I / O terminal, and a spare terminal.
  • the SIM card 306 is provided from a mobile communication service provider (MNO) or a virtual mobile communication service provider (MVNO) when the user subscribes to the mobile communication service.
  • MNO mobile communication service provider
  • MVNO virtual mobile communication service provider
  • the data and programs stored in the SIM card 306 differ for each business operator, but the basic structure of the SIM card 306 itself is the same as long as it conforms to international standards.
  • a micro-SIM is described as an example, but a mini-SIM or a nano-SIM can be used as a SIM card.
  • the IC card 307 has the same or substantially the same size as the SIM card 306 in width and height, and has a structure in which the IC chip 41 is embedded in a flexible film having a thickness of about 0.1 to 0.2 mm.
  • the IC chip 41 also has a processor 411, a RAM 412, a nonvolatile memory 413, and eight pins (electrodes) 414.
  • the non-volatile memory 413 of the IC card 307 stores data and programs for realizing secure use of the online service (details will be described later).
  • the eight pins 414 of the IC card 307 are exposed on both the front and back surfaces of the IC card 307, and have the same arrangement as the eight pins 404 of the SIM card 306. As shown in FIG. 4, by sticking this IC card 307 on the SIM card 306 so that the corresponding pins (electrodes) of the IC card 307 and the SIM card 306 are physically and electrically connected to each other. Become. Since the IC card 307 is extremely thin, the SIM card 306 to which the IC card 307 is attached can be inserted into the SIM card slot 308 of the user device 30.
  • FIG. 5 schematically shows a state in which the IC card 307 and the SIM card 306 are mounted in the SIM card slot 308.
  • the pins 414 on the surface of the IC card 307 are connected to the terminals 310 of the control board 309 of the user device 30, and the pins 404 of the SIM card 306 are connected to the terminals 310 of the control board 309 via the pins 414 of the IC card 307. It becomes.
  • the CPU 300 of the user device 30 can selectively access any of the IC card 307 and the SIM card 306.
  • the application program operated by the CPU 300 of the user device 30 can selectively switch between a mode for communicating with the IC card 307 and a mode for communicating with the SIM card 306.
  • the processor 411 of the IC card 307 processes a signal (command) received from the user device 30 by itself and does not transmit the signal (command) to the SIM card 306.
  • the processor 411 of the IC card 307 performs an operation of mediating (through) a signal between the user device 30 and the SIM card 306.
  • the IC card 307 of the type that is overlaid on the communication SIM card 306 is also called a “sub SIM”.
  • the use of the sub SIM type IC card 307 has the following advantages. If the mobile device has a SIM card slot, the IC card 307 can be mounted (that is, no special structure or work is required on the mobile device side, and the IC card 307 can be mounted on almost all mobile devices). Is possible). The IC card 307 can be attached to a portable device having only one SIM card slot (in other words, even if there is no empty SIM card slot). Further, since the communication SIM card 306 and the IC card 307 are completely independent in function and do not affect each other, the voice communication and the data communication can be performed even after the IC card 307 is attached. It can be used as well. Moreover, since it can be added to the SIM card of any business, introduction and dissemination are easy.
  • FIG. 6 is a block diagram schematically illustrating a logical configuration of the user device 30 and the IC card 307.
  • the user device 30 has installed therein an application program 60 (hereinafter simply referred to as “main application 60”) for using the intermediate service provided by the intermediate server 21.
  • the main body application 60 is a program distributed by an intermediate service provider (an agent such as an electronic payment in the case of the present embodiment), and the user downloads the main body application 60 through an application distributor on the Internet before using the intermediate service. Download and install.
  • the main application 60 has a main processing unit 600, a user authentication unit 601, and a security processing unit 602 as main functions.
  • the main processing unit 600 has a function of controlling display and input of a use screen of the intermediate service, transmitting and receiving data to and from the intermediate server 21, and the like.
  • the user authentication unit 601 has a function of confirming the validity of a person who uses the user device 30. The user authentication here is intended to confirm whether the person who is actually operating the user device 30 is a valid person (the user himself or a person who has been authorized by a valid user).
  • the security processing unit 602 is a function that executes security processing such as data encryption and electronic signature using the function of the IC card 307.
  • the non-volatile memory 413 (hereinafter, simply referred to as “memory 413”) of the IC card 307 stores personal information 610 used for the above-described user authentication, a pair of the user's private key 611 and public key 612, and the user's digital certificate 613. , A hash function 614, a program 615, and the like.
  • the address space of the memory 413 has an area 4130 that can be accessed (read and written) from outside, and an area 4131 that cannot be accessed from outside (that is, an area that can be accessed only by the processor 411 of the IC card 307) 4131. .
  • Data used in the security processing are all stored in the area 4131, and are externally (for example, the main body application 60). Is not directly readable and writable. Data such as the serial number 616 and the serial number 617 of the IC card 307 are stored in the area 4130 and can be read from the outside.
  • the processor 411 of the IC card 307 provides some APIs (Application Programming Interface) for the security function to an external application.
  • APIs Application Programming Interface
  • FIG. 6 as an example, an authentication function 620, an encryption function 621, an electronic signature function 622, a personal information change function 623, a key generation function 624, a public key read function 625, an electronic certificate write function 626, and an electronic certificate read Function 627 is shown. These functions are realized by the processor 411 executing the program 615.
  • the authentication function 620 is a function of performing user authentication by comparing information provided from the outside with personal information 610 stored in the memory 413. Functions 621 to 627 other than the authentication function 620 cannot be used unless user authentication is successful. Any method of user authentication may be used. For example, in the case of PIN code authentication, the authentication function 620 receives a code (for example, a four-digit number) input by the user from the user authentication unit 601 of the main application 60, and the input code is registered as the personal information 610 in the PIN. It checks whether the codes match, and returns a result of "OK" if they match, and "NG” if they do not match.
  • a code for example, a four-digit number
  • the authentication function 620 receives a password (for example, a password of 6 to 16 characters) input by the user from the user authentication unit 601 of the main body application 60, and the input password is registered as the personal information 610. The result is "OK” if they match, and "NG” if they do not match.
  • the authentication function 620 receives the user's biometric information (face image, voiceprint, iris, fingerprint, vein, etc.) from the user authentication unit 601 of the main application 60, and extracts features from the biometric information. Then, it is determined whether or not the user is the principal by comparing the personal characteristic registered as the principal information 610.
  • a result of "OK” is returned, and if not, a result of "NG” is returned.
  • Higher security may be realized by combining two or more of PIN code authentication, password authentication, and biometric authentication, or by combining another authentication method.
  • the encryption function 621 is a function for encrypting externally provided data using the secret key 611.
  • the encryption function 621 receives data from the security processing unit 602 of the main application 60, encrypts the data using the secret key 611, and returns encrypted data (cipher text).
  • the encryption algorithm is preferably RSA, DSA, ECDSA or the like, but other algorithms may be used.
  • the electronic signature function 622 is a function for performing an electronic signature using secret key 611 on data given from the outside.
  • the difference from the encryption function 621 is that the given data itself is not encrypted but the hash value of the given data is encrypted.
  • the electronic signature function 622 receives data from the security processing unit 602 of the main application 60, calculates a hash value using the hash function 614, encrypts the hash value using the secret key 611, and outputs the encrypted hash value. return.
  • Any hash function may be used (in the present embodiment, SHA-1 and SHA-256 are used). When the size of the data to be subjected to the electronic signature is small, an encrypted version of the data itself may be used as the electronic signature instead of the hash value.
  • the principal information change function 623 is a function of writing the principal information 610 in the memory 413 and updating or deleting the principal information 610 stored in the memory 413. This function is used when the main body application 60 newly registers or changes user information in the IC card 307.
  • the key generation function 624 is a function for generating a key pair of the secret key 611 and the public key 612.
  • information associated with the user such as the personal information 610, the secret key 611, the public key 612, and the electronic certificate 613, is not stored in the memory 413, and the IC card issuance procedure described later is not performed. Sometimes it is registered in the memory 413 (this operation is called activation of the IC card).
  • activation of the IC card since the secret key 611 is generated and stored in the memory 413 in a closed space in the IC card 307, the risk of the secret key 611 being leaked can be reduced.
  • an API for reading the secret key 611 from the memory 413 is not prepared, the risk that the secret key 611 leaks to the outside is almost zero.
  • the public key read function 625 is a function for reading the public key 612 from the memory 413.
  • the electronic certificate writing function 626 is a function of writing the electronic certificate 613 in the memory 413
  • the electronic certificate reading function 627 is a function of reading the electronic certificate 613 from the memory 413. Since the public key 612 and the electronic certificate 613 are for distributing to the communication partner, they can be read outside. Note that writing of the electronic certificate 613 is required at the time of the IC card issuance procedure.
  • the main body application 60 of the user device 30 can easily realize data encryption and electronic signature using public key encryption by using the IC card 307.
  • user authentication is required to use the encryption and digital signature functions of the IC card 307, and the risk of leaking a secret key is almost zero, so that extremely robust security is ensured.
  • FIG. 7 is a diagram showing an IC card issuing terminal
  • FIG. 8 is a diagram showing a flow of an IC card issuing procedure.
  • the IC card issuing terminal 70 is a terminal that issues a new IC card 307, and is installed in, for example, a mobile phone shop, a store (such as a bank) of a service provider, a convenience store, or an agent window.
  • the IC card issuing terminal 70 is configured by a computer including an IC card reader / writer.
  • a general-purpose personal computer or tablet terminal may be used if operated by a store clerk, or a kiosk terminal may be used if operated by a user (applicant of an IC card).
  • the issuing procedure will be described with reference to FIG.
  • the "user” is a person who newly applies for the IC card 307 to use the online service (referred to as “user” or “applicant” in the description of FIG. 8).
  • the “contact” is a person who performs an IC card 307 issuing operation using the IC card issuing terminal 70.
  • the “communication service manager” is a person responsible for managing issuance and operation of the IC card 307.
  • the communication service administrator provides the IC card 307, applies for an electronic certificate to a certificate authority, manages the issued IC card, manages the association between the IC card 307 and the SIM card 306, and invalidates the IC card 307 ( For example, when the user device 30 is lost, stolen, or disposed of).
  • the communication service manager may be constituted by a business entity different from the online service provider or the intermediate service provider.
  • the “certificate authority” is a person who issues and revokes electronic certificates of public keys.
  • the IC card applicant applies for the use of the IC card at the window (step S800).
  • the personal identification information may include, for example, name, gender, date of birth, and address.
  • the applicant specifies a PIN code to be registered in the IC card.
  • the counter staff confirms the identity by comparing the information transmitted from the applicant with the identity verification document, and then inputs the information to the IC card issuing terminal 70 (step S801).
  • only the input of the PIN code may be performed by the applicant in order to prevent the contact staff from knowing the PIN code.
  • the counter staff sets a new IC card 307 in the IC card issuing terminal 70 and instructs the start of activation processing.
  • the memory 413 of the IC card 307 only the “hash function 614, the program 615” of the information shown in FIG. 6 is stored, and the “secret key 611, public key 612” which is information associated with the user.
  • Electronic certificate 613 has not been stored yet, and the PIN code of the personal information 610 is an initial value (for example,“ 0000 ”).
  • the IC card issuing terminal 70 uses the authentication function 620 to perform authentication using the initial PIN code, and then uses the principal information change function 623 to register the PIN code specified by the applicant, and The generation function 624 is instructed to generate a key pair, and the secret key 611 and the public key 612 are generated (step S802).
  • the PIN code and the key pair are written in a predetermined area 4131 of the memory 413.
  • the IC card issuing terminal 70 reads the public key 612 from the memory 413 using the public key read function 625, and uses the public key 612 and the personal identification information input in step S801 to perform a CSR (Certificate Signing Request). Is created and transmitted to the management server of the communication service manager (step S803).
  • CSR Certificate Signing Request
  • the management server Upon receiving the CSR from the IC card issuing terminal 70, the management server transmits the CSR to a predetermined certificate authority (step S804). At this time, the management server may carry out a credit check of the applicant based on the identification information.
  • the certificate authority issues an electronic certificate of the applicant's public key according to the received CSR and sends it to the management server (step S805).
  • An electronic certificate certifies a public key and its owner. X.2, which was formulated by ITU-T.
  • the electronic certificate is data including a public key, owner information (corresponding to personal identification information), an electronic signature of a certificate authority, an expiration date of the electronic certificate, and information on the issuer.
  • the digital signature of the certificate authority is obtained by encrypting a hash value generated from the public key and owner information included in the digital certificate with the secret key of the certificate authority.
  • the management server sends the issued electronic certificate to the IC card issuing terminal 70 (Step S806).
  • the IC card issuing terminal 70 writes the electronic certificate in the memory 413 using the electronic certificate writing function 626 of the IC card 307 (step S807).
  • the personal information 610 PIN code in this embodiment
  • the private key 611, the public key 612, and the electronic certificate 613, which are data necessary for security processing, are provided in the memory 413 of the IC card 307. become.
  • the IC card 307 is attached to the user device 30 of the applicant (step S808). Specifically, the SIM card 306 for communication is taken out from the user device 30, the IC card 307 is pasted on the SIM card 306, and then the SIM card 306 is inserted into the user device 30 again. Further, the setup program is installed in the user device 30, and the setup process of the IC card 307 is executed by the setup program. Attachment and setup of the IC card 307 may be performed by the counter staff or by the applicant himself.
  • the user device 30 (a setup program that operates) reads the “serial number” and “serial number” from the IC card 307 and the “telephone number” and “serial number” from the SIM card 306.
  • the setup program acquires “IMEI (International Mobile Equipment Equipment)” as information of the user device 30 itself.
  • the setup program sends an IC card registration request to the management server of the communication service manager together with the information (step S809).
  • the management server Upon receiving the IC card registration request from the user device 30, the management server registers the information of the IC card 307, the SIM card 306, and the user device 30 included therein in the IC card management database (step S810).
  • FIG. 9 shows an example of the data structure of IC card management information stored in the IC card management database.
  • the “telephone number” and “serial number” of the SIM card 306 and the “IMEI” of the user device 30 are managed in association with the “serial number” and “serial number” of the IC card 307.
  • user identification information name, gender, address, date of birth
  • public key public key
  • electronic certificate information and the like may be managed as IC card management information.
  • the management server When the registration of the IC card management information is completed, the management server notifies the user device 30 of the completion of the registration (step S811). As a result, the setup of the user device 30 is completed, and the IC card 307 can be used (activated).
  • the issuance procedure shown in FIG. 8 is merely an example, and the issuance procedure may be performed in a different procedure.
  • an IC card 307 in which a secret key, a public key, an electronic certificate, and a PIN code are registered in advance may be prepared at the counter.
  • the IC card issuing terminal 70 since writing to the IC card 307 is not necessary, the IC card issuing terminal 70 does not need to be used, and only the setup process in the user device 30 is sufficient, and the IC card issuing procedure is simplified.
  • biometric authentication is used instead of PIN code authentication, biometric information (face image, voiceprint, iris, fingerprint, etc.) to be registered as personal information in the IC card 307 is input using the IC card issuing terminal 70 or the like. do it.
  • FIG. 10 and FIG. 11 are diagrams showing the flow of the registration procedure for the intermediate service
  • FIG. 12 is an example of a screen displayed on the user device 30.
  • the user registration for the online service has already been completed, and the user has been given an ID and password for logging in to the online service itself.
  • the user operates the user device 30 to download and install the main application 60 (step S1001). Then, the user activates the main body application 60 and opens a log-in screen for the intermediate service (step S1002). As shown in FIG. 12, when logging in for the first time, the user inputs the user ID and password of the intermediate service on the login screen 120 and logs in to the intermediate service (step S1003). At this time, the main body application 60 stores the user ID of the intermediate service in the nonvolatile memory (Step S1004). It is better not to store the password in the user device 30 from the viewpoint of security. The user ID and the password are information provided by the intermediate service provider when a new application for the intermediate service, which is a separate procedure, is made.
  • the intermediate server 21 transmits a predetermined electronic message (contents may be arbitrary) to the user device 30, and requests an electronic signature and an electronic certificate (step S1005).
  • the user authentication unit 601 of the main body application 60 displays the PIN code input screen 121 as shown in FIG.
  • the user authentication unit 601 uses the authentication function 620 of the IC card 307 to check whether the input PIN code is correct (step S1006).
  • the PIN code is correct (that is, when the user authentication is successful)
  • other functions 621 to 627 of the IC card 307 can be used from the main body application 60.
  • the security processing unit 602 of the main body application 60 uses the electronic signature function 622 of the IC card 307 to perform an electronic signature on the message received from the intermediate server 21, and uses the electronic certificate read function 627 to store the memory 413. From the electronic certificate 613. Then, the main processing unit 600 of the main body application 60 transmits the electronic signature-attached electronic message and the electronic certificate 613 to the intermediate server 21 (Step S1007).
  • the intermediate server 21 verifies the electronic signature-added message using the electronic certificate 613 received from the user device 30 (step S1008).
  • “Verification” means that the electronic signature is performed by the user himself / herself by decrypting the electronic signature-attached electronic message using the public key included in the electronic certificate 613 and checking whether the decrypted result matches the original electronic message (ie, , An electronic signature has been created with the user's private key).
  • the decryption result may be compared with the original message.
  • the decryption result and the original message may be compared. What is necessary is just to compare with the hash value of a telegram.
  • the intermediate server 21 associates the user ID / password of the user with the electronic certificate and registers it in the user information storage unit 211 (step S1009). Then, the intermediate server 21 notifies the main application 60 that registration of the electronic certificate has been completed (step S1010). When the registration for the intermediate service is completed, a menu screen 122 is displayed on the user device 30, as shown in FIG. 12 (step S1011).
  • FIGS. 10 and 11 show an example in which the user makes a balance inquiry.
  • Step S1012 When the user selects “Balance Inquiry” from the menu screen 122 and inputs information of the target bank account (bank name, account number, account name, etc.), the main body application 60 transmits a balance inquiry request to the intermediate server 21. (Step S1012).
  • the proxy control unit 213 of the intermediate server 21 issues a balance inquiry request to the service providing server 20 of the bank of the inquiry destination (step S1013).
  • This balance inquiry request includes the user's bank account information.
  • the access control unit 202 of the service providing server 20 requests the user to input the ID and password of the online service (step S1014). Specifically, as shown in FIG. 12, a login screen 123 of the online service is displayed on the user device 30 (step S1015), and the user inputs the user ID and password of the online service and logs in to the online service. (Step S1016).
  • the service providing server 20 transmits an authentication message (any content may be used) to the user device 30, and requests an electronic signature and an electronic certificate (step S1017).
  • the user authentication unit 601 of the main body application 60 displays the PIN code input screen 124 as shown in FIG.
  • the user authentication unit 601 uses the authentication function 620 of the IC card 307 to check whether the input PIN code is correct (step S1018).
  • the PIN code is correct (that is, when the user authentication is successful)
  • other functions 621 to 627 of the IC card 307 can be used from the main body application 60.
  • the security processing unit 602 of the main body application 60 performs an electronic signature on the authentication message received from the service providing server 20 using the electronic signature function 622 of the IC card 307, and uses the electronic certificate reading function 627.
  • the electronic certificate 613 is read from the memory 413.
  • the main processing unit 600 of the main body application 60 transmits the electronic signature-added authentication message and the electronic certificate 613 to the service providing server 20 (step S1019). At this time, the main body application 60 stores the authentication message in the non-volatile memory (Step S1020).
  • the service providing server 20 verifies the electronic signature-added authentication message using the electronic certificate 613 received from the user device 30 (step S1021). If the verification is successful, the service providing server 20 issues an access token to the pair of the user and the intermediate service.
  • the proxy of the online service by the intermediate server 21 is realized using the mechanism of OAuth 2.0.
  • the access token is like a permit when the intermediate server 21 uses the online service on behalf of the user.
  • the user registration unit 200 associates the authentication message, the access token, and the electronic certificate of the user with each other and registers them in the user information storage unit 201 (step S1023).
  • the service providing server 20 notifies the intermediate server 21 of the issued access token and information on the account balance of the user (step S1024).
  • the intermediate server 21 associates the received access token with the ID of the intermediate service of the user and registers it in the user information storage unit 211 (step S1025).
  • the intermediate server 21 also receives a refresh token from the service providing server 20 together with the access token.
  • the refresh token is a token used for reissuing an access token. Since this is a specification of OAuth 2.0, detailed description is omitted here.
  • the intermediate server 21 notifies the main application 60 of the account balance information (step S1026).
  • an account balance confirmation screen 125 is displayed on the user device 30 (step S1027).
  • FIG. 13 is a diagram showing a flow of login authentication of the intermediate service
  • FIG. 14 is an example of a screen displayed on the user device 30.
  • the user authentication unit 601 displays a PIN code input screen 140 as shown in FIG. 14 (step S1300).
  • the user authentication unit 601 uses the authentication function 620 of the IC card 307 to check whether the input PIN code is correct (step S1301).
  • the security processing unit 602 of the main application 60 uses the electronic signature function 622 of the IC card 307 to transmit the intermediate service user ID and the authentication message.
  • An electronic signature is performed (step S1302).
  • the main processing unit 600 of the main application 60 transmits a login request to the intermediate server 21 (Step S1303).
  • the login request includes a user ID of the intermediate service, an authentication message, and an electronic signature.
  • the login control unit 212 of the intermediate server 21 Upon receiving the login request, the login control unit 212 of the intermediate server 21 reads the corresponding electronic certificate from the user information storage unit 211 based on the user ID included in the login request, and logs in using this electronic certificate. The electronic signature included in the request is verified (step S1304). If necessary, the login control unit 212 may inquire of the certificate authority about the validity of the electronic certificate (steps S1305 and S1306). If the verification of the electronic signature is successful and the validity of the electronic certificate is confirmed, the login control unit 212 determines that the login request is from a valid user.
  • the login control unit 212 of the intermediate server 21 reads out the access token of the online service from the user information storage unit 211 based on the user ID included in the login request, and transmits the access request to the service providing server 20 (step). S1307).
  • the access request includes an access token, an authentication message and an electronic signature included in the login request.
  • the access control unit 202 of the service providing server 20 Upon receiving the access request, the access control unit 202 of the service providing server 20 reads the corresponding electronic certificate from the user information storage unit 201 based on the access token included in the access request, and uses the electronic certificate to The digital signature included in the access request is verified (step S1308). If necessary, the access control unit 202 may inquire of the certificate authority about the validity of the electronic certificate (steps S1309 and S1310). If the verification of the digital signature is successful and the validity of the digital certificate is confirmed, the access control unit 202 determines that the access request is from the intermediate server 21 to which the user has been given the proxy authority. Then, access permission is given to the intermediate server 21 (step S1311).
  • the intermediate server 21 When the access permission for the online service is obtained, the intermediate server 21 notifies the main body application 60 of the login authentication OK (step S1312). Thereafter, as shown in FIG. 14, a menu screen 141 of the intermediate service is displayed on the user device 30, and the user can perform a desired procedure.
  • the login authentication described above since the user only needs to enter the PIN code, the login can be performed with a very simple operation as compared with the conventional method of inputting the ID and password each time or the method of using the token. It becomes. Moreover, since the security function provided by the IC card 307 is used, a high level of security is ensured.
  • the intermediate service and the online service can be linked without providing any information of the ID and password of the online service to the intermediate service. Therefore, even a user who feels reluctant to disclose the online banking ID / password to another business can use this service with confidence.
  • FIG. 15 is a diagram showing a flow when using the intermediate service
  • FIG. 16 is an example of a screen displayed on the user device 30. It is assumed that the login to the intermediate service has already been completed, and the menu screen 160 is displayed on the user device 30.
  • step S1500 When the user selects a procedure to be used from the menu screen 160, the screen transits to the detail screen 161 (step S1500).
  • FIG. 16 shows a screen example when the user selects “transfer”.
  • the main processing unit 600 of the main application 60 transmits information necessary for the transfer procedure.
  • the described procedure message is created (step S1502).
  • the user authentication unit 601 of the main body application 60 displays the PIN code input screen 162 and performs PIN code authentication (step S1503). Since the procedure of PIN code authentication is the same as that described above, the description is omitted.
  • the security processing unit 602 of the main application 60 performs an electronic signature on the procedure message by using the electronic signature function 622 of the IC card 307 (step S1504).
  • the electronic signature function 622 may calculate a hash value of the procedure message and generate an electronic signature by encrypting the hash value with the secret key 611, or encrypt the procedure message itself with the secret key 611.
  • the digital signature may be generated by the conversion.
  • the main processing unit 600 of the main application 60 transmits a procedure request to the intermediate server 21 (Step S1505). The ID of the intermediate service, the procedure message, and the electronic signature are added to the procedure request.
  • the proxy control unit 213 of the intermediate server 21 Upon receiving the procedure request, the proxy control unit 213 of the intermediate server 21 reads out the corresponding electronic certificate from the user information storage unit 211 based on the user ID included in the procedure request, and uses the electronic certificate to execute the procedure. The digital signature included in the request is verified (step S1506). Further, the proxy control unit 213 may inquire of the certificate authority about the validity of the electronic certificate as necessary (steps S1507 and S1508). If the verification of the electronic signature is successful and the validity of the electronic certificate is confirmed, the proxy control unit 213 determines that the procedure request is from a valid user. That is, it is determined that there is no impersonation by a third party and that the contents of the procedure message have not been falsified.
  • the proxy control unit 213 When it is confirmed that the procedure request is from a valid user, the proxy control unit 213 reads the access token of the corresponding online service from the user information storage unit 211 based on the user ID and the procedure message included in the procedure request. And sends a procedure request to the service providing server 20 (step S1509).
  • the procedure request includes an access token, a procedure message received from the user device 30, and an electronic signature.
  • the procedure control unit 203 of the service providing server 20 Upon receiving the procedure request, the procedure control unit 203 of the service providing server 20 reads the corresponding electronic certificate from the user information storage unit 201 based on the access token included in the procedure request, and uses the electronic certificate to The electronic signature included in the procedure request is verified (step S1510). Further, if necessary, the procedure control unit 203 may inquire of the certificate authority about the validity of the digital certificate (steps S1511, S1512). If the verification of the electronic signature is successful and the validity of the electronic certificate is confirmed, the procedure control unit 203 determines that the procedure request is from a valid user. That is, it is determined that there is no impersonation by a third party and that the contents of the procedure message have not been falsified.
  • the procedure control unit 203 executes a procedure (transfer or the like) based on the information described in the procedure message (step S1513).
  • the procedure control unit 203 transmits a procedure completion notification to the intermediate server 21 (Step S1514), and the intermediate server 21 transmits a procedure completion notification to the main application 60 (Step S1515). Then, as shown in FIG. 16, a procedure completion screen 163 is displayed.
  • the user only needs to input the PIN code, so that the intermediate service and the online service can be performed with a very simple operation as compared with the conventional method of inputting the ID and password each time and the method of using the token.
  • the service can be used.
  • the security function provided by the IC card 307 is used, a high level of security is ensured, and it is possible to prevent impersonation due to a so-called man-in-the-middle attack and falsification of the procedure message.
  • the procedure request sent from the user device 30 includes a plaintext procedure message. This is to enable the intermediate server 21 (intermediate service provider) to verify whether the procedure message has been tampered with.
  • the procedure message contains information that the user other than the service provider does not want to know or need not convey.
  • the message of the procedure will include the address information after the change, but since personal information such as the address is related to privacy, the intermediate service provider will be informed. Many users do not want to be asked.
  • banks have a legal obligation to manage address information, but intermediate service providers do not, so intermediate service providers may want to avoid receiving unnecessary personal information. Absent.
  • the user device 30 may encrypt the procedure message using the public key of the service providing server 20 (service provider). That is, after the main body application 60 of the user device 30 encrypts a procedure message such as an address change procedure using the public key of the service providing server 20, the main body application 60 performs an electronic signature using the user's private key 611 on the encrypted procedure message. , A procedure request including an ID, an encrypted procedure message, and an electronic signature are transmitted to the intermediate server 21.
  • the intermediate server 21 can confirm that the procedure request has been sent from a legitimate user, but cannot confirm the content of the procedure message.
  • the service providing server 20 can confirm the contents of the procedure message (such as address information of the user) by decrypting the procedure message using the secret key stored therein, and can perform the procedure. Therefore, it is possible to realize a mechanism in which information is transmitted only to the service provider in a state of being concealed from the intermediate service provider while passing through the intermediate service by the intermediate service provider.
  • the intermediate service and the online service cannot be used unless the user authentication based on the PIN code or the biometric information is successful. Therefore, even if the user device 30 is lost or stolen, the risk of unauthorized use of the user device 30 by a third party is small.
  • PIN code authentication or biometric authentication can be broken is not zero, it is preferable to implement an IC card invalidation function as described below.
  • IC Card Self-Destruction Function Self-destruction is an operation in which the processor 411 of the IC card 307 invalidates the function of the IC card 307. Specific operations include locking the function of the IC card 307 so that the function of the IC card 307 cannot be used from outside (the main body application 60), or deleting data (key pair, digital certificate, etc.) stored in the memory 413. There are ways to do that. For example, the processor 411 may execute self-destruction when an incorrect PIN code is continuously input a predetermined number of times or when the memory 413 is accessed by a method other than the API.
  • the management server invalidates the user device 30 or the IC card 307.
  • the IC card 307 may be invalidated by transmitting an activation signal.
  • the management server monitors the use status of the IC card 307 and detects an abnormality (for example, when the non-use state continues for a long time, when the frequency of use suddenly increases, or when an attempt is made to remit large sums of money) Etc.), the IC card 307 may be invalidated.
  • the management server monitors a combination of the IC card 307, the SIM card 306, and the user device 30, and detects a discrepancy with the information managed by the IC card management information (for example, the IC card alone or the SIM card).
  • the IC card 307 may be invalidated when such an inconsistency occurs when the IC card 307 is removed together with the portable device and is attached to another portable device.
  • the invalidation method also locks the function of the IC card 307 so that the function of the IC card 307 cannot be used from outside (the main body application 60), or erases data (key pair, digital certificate, etc.) stored in the memory 413. There are methods.
  • the management server sends the electronic certificate of the user to the certificate authority. May be requested to invalidate the certificate.
  • the management server may monitor the use status of the IC card 307 and the combination of the IC card, the SIM card, and the user device, and may request the certificate authority to invalidate the electronic certificate when an abnormality is detected.
  • the above-described embodiment merely describes one specific example of the present invention, and the technical scope of the present invention is not limited to the contents of the above-described embodiment, and the present invention is not limited to the scope of the technical idea. It can take various concrete forms.
  • the present invention can be applied to various types of online services other than the online banking service.
  • the sub SIM type IC card is exemplified.
  • an IC card having the same specification as a general micro-SIM or nano-SIM (for communication) is used. It may be installed in a separate slot from the SIM card).
  • an IC card of a type mounted in a slot other than the SIM card slot may be used, or an IC chip (for example, a Secure Element or the like) built in the portable device may be used.
  • an electronic certificate may be sent together.
  • the electronic signature is performed only on the data transmitted from the user device to the intermediate server.
  • the intermediate server or the service providing server performs the electronic signature or encryption on the data transmitted to the user device. In that case, the intermediate server or the service providing server may perform an electronic signature or encryption using its own encryption key, or may perform encryption using a user's public key.
  • FIG. 17 is a block diagram schematically illustrating a hardware configuration of the user device 30 including the secure element 1600.
  • the secure element 1600 is an IC chip that has resistance (tamper resistance) to stored data from being externally analyzed and is mainly used to manage confidential information.
  • the secure element 1600 is an IC chip independent of the control board 309 (including the processor 1611, the RAM 1612, and the nonvolatile memory 1613) of the user device 30, and includes the processor 1601, the RAM 1602, and the nonvolatile memory 1603.
  • the secure element 1600 communicates with the processor 1611 of the user device 30 or the like.
  • data used in the encryption function (identity information 610, secret key 611, public key 612, electronic certificate 613, hash function 614, program 615, etc. shown in FIG. 6) It may be stored in the nonvolatile memory 1603 in the secure element 1600. Also, an encryption function (authentication function 620, encryption function 621, electronic signature function 622, personal information change function 623, key generation function 624, public key read function 625, electronic certificate write function 626, The electronic certificate reading function 627 and the like may be provided by the processor 1601 of the secure element 1600 executing the program 615.
  • the user device can use the online service alone, which is highly convenient. Also, since automatic login is possible only by launching the application and authenticating the user, smart and simple operability can be realized. Further, since the secret key stored in the secure element 1600 and the encryption function provided by the secure element 1600 are used, secure data communication can be realized. This private key has a low risk of leakage, and cannot use the secret key or the encryption function without clearing the PIN code, password, or biometric authentication, thus reducing the risk of unauthorized use by a third party. It can be as small as possible.
  • FIG. 18 is a block diagram schematically illustrating a hardware configuration of the user device 30 including the SIM card 1700.
  • the SIM card 1700 has a processor 1701, a RAM 1702, a nonvolatile memory 1703, and eight pins 1705 (electrodes).
  • the nonvolatile memory 1703 stores data such as a unique serial number (ICCID) and subscriber identification information (IMSI) of the SIM card 1700, data used for an encryption function, and a program executed by the processor 1701. Have been.
  • the eight pins 1705 include a power input terminal, a reset terminal, a clock terminal, a ground terminal, a program voltage input terminal, an I / O terminal, and a spare terminal.
  • FIG. 18 schematically shows a state in which the SIM card 1700 is mounted in the SIM card slot 1704.
  • the pin 1705 of the SIM card 1700 is connected to the terminal 1706 of the control board 309 of the user device 30.
  • the SIM card 1700 is provided by a mobile communication service provider (MNO) or a virtual mobile communication service provider (MVNO) when the user subscribes to the mobile communication service.
  • MNO mobile communication service provider
  • MVNO virtual mobile communication service provider
  • the data and programs stored in the SIM card 1700 are different for each company, but the basic structure of the SIM card 1700 itself is the same as long as it conforms to international standards.
  • any of a standard-SIM, a micro-SIM, and a nano-SIM may be used.
  • data (identity information 610, a secret key 611, a public key 612, a digital certificate 613, a hash function 614, a program 615, and the like shown in FIG. 6) used in the encryption function are It may be stored in the nonvolatile memory 1703 in the SIM card 1700.
  • an encryption function (authentication function 620, encryption function 621, electronic signature function 622, personal information change function 623, key generation function 624, public key read function 625, electronic certificate write function 626, The electronic certificate reading function 627 and the like may be provided by the processor 1601 of the SIM card 1700 executing the program 615.
  • the user device can use the online service alone, which is highly convenient.
  • automatic login is possible only by launching the application and authenticating the user, smart and simple operability can be realized.
  • the secret key stored in the SIM card 1700 and the encryption function provided by the SIM card 1700 are used, secure data communication can be realized.
  • This private key has a low risk of leakage, and cannot use the secret key or the encryption function without clearing the PIN code, password, or biometric authentication, thus reducing the risk of unauthorized use by a third party. It can be as small as possible.
  • the applicant (user) of the IC card applies for use of the IC card at the counter (step S1800).
  • the user's identification information and telephone number are input to the procedure terminal, and identification documents (driver's license, resident's card, etc.) are submitted.
  • the personal identification information may include, for example, name, gender, date of birth, and address.
  • the telephone number is a telephone number assigned to a communication SIM card mounted on the user device 30.
  • the user inputs the personal identification information and the telephone number to the procedure terminal (step S1801).
  • the identification document may be converted into electronic data (for example, image data) by a camera or a scanner provided in the procedure terminal.
  • the procedure terminal transmits the personal identification information, the personal identification document, and the telephone number to the communication service manager (Step S1802).
  • the user himself operates the procedure terminal and inputs necessary information.
  • the counter staff may perform the input.
  • the user installs a predetermined program (called a “setup program”) for installing and activating the encryption function in the user device 30 (the main body application 60 shown in FIG. 6 may also serve as the setup program). ).
  • the processor of the user device 30 reads the telephone number and the IMSI from the SIM card for communication using the setup program (step S1803), and transmits the telephone number and the IMSI of the SIM card to the communication service manager (step S1804).
  • the user receives the IC card and mounts it on the user device 30.
  • the “hash function, program” of the information shown in FIG. 6 is stored in the memory of the IC card, and the “private key, public key, digital certificate” which is information associated with the user is Not yet stored.
  • the communication service administrator associates the information received from the user device 30 with the information received from the procedure terminal using the telephone number as a key, and associates the personal identification information with the personal identification document, the telephone number of the SIM card, and the IMSI. To remember. Then, the communication service administrator checks the personal identification information by checking the personal identification information with the personal identification document and checking whether there is any inconsistency in the information (step S1806). After the identification is completed, the communication service manager transmits the certificate issuing request and the telephone number and / or IMSI of the communication SIM card received from the user device 30 to the certificate authority (step S1807).
  • the user device 30 indirectly notifies the certificate authority of the telephone number and / or IMSI via the communication service manager, but the user device 30 directly notifies the certificate number of the telephone number and / or IMSI. You may be notified.
  • the electronic data of the personal identification document is transmitted to the communication service administrator via the network.However, if it is necessary to confirm the original of the personal identification document, the contact person or the user provides the communication service administrator with the personal identification document. The original may be submitted or mailed. In this case, after the communication service manager receives the original of the personal identification document, the personal identification processing in step S1806 is started.
  • the certificate authority Upon receiving the certificate issuance request, the certificate authority generates a user identification code and transmits the user identification code to the destination specified by the IMSI or the telephone number (step S1808).
  • a means for transmitting the user identification code for example, SMS (Short Message Service) can be used.
  • the setup program of the user device 30 instructs the key generation function 624 of the IC card to generate a key pair to generate a secret key and a public key (step S1809).
  • the order of sending the user identification code (step S1808) and generating the key pair (step S1809) does not matter.
  • the setup program of the user device 30 reads the public key from the memory of the IC card using the public key reading function 625 of the IC card, and issues a digital certificate issuance request based on the public key and the user identification code.
  • a certain CSR (Certificate ⁇ Signing ⁇ Request) is created and transmitted to a predetermined certificate authority (step S1810).
  • the certificate authority issues a digital certificate of the user's public key in accordance with the received CSR, and transmits the digital certificate to the user device 30 via the wired Internet or the wireless Internet (step S1811).
  • transmission may be performed using HTTP (Hypertext Transfer Protocol) or HTTPS (Hypertext Transfer Protocol Secure).
  • HTTP Hypertext Transfer Protocol
  • HTTPS Hypertext Transfer Protocol Secure
  • Electronic certificates are used to electronically prove that a user is who he claims to be.
  • a public key certificate that associates a public key with identification information of its owner is used as the electronic certificate.
  • X.2 which was formulated by ITU-T.
  • the electronic certificate is data including a public key, owner information (corresponding to personal identification information), an electronic signature of a certificate authority, an expiration date of the electronic certificate, and information on the issuer.
  • the digital signature of the certificate authority is obtained by encrypting a hash value generated from the public key and owner information included in the digital certificate with the secret key of the certificate authority.
  • the timing at which the certificate authority transmits the electronic certificate to the user device 30 or the timing at which the user device 30 receives the digital certificate from the certificate authority can be arbitrarily controlled.
  • the setup program of the user device 30 periodically communicates with the certificate authority in the background to check whether or not the issuance of the electronic certificate has been completed. Is also good.
  • the certificate authority may notify the user device 30 of the scheduled date and time (date and time at which download is possible) of the electronic certificate.
  • the setup program of the user device 30 may access the certificate authority and obtain the electronic certificate after the notified scheduled issuance date and time.
  • the certificate authority notifies the setup program of the user device 30 that the issuance of the electronic certificate has been completed, and transmits the electronic certificate to the setup program that has responded. Is also good.
  • the request for issuing the electronic certificate and the transmission of the electronic certificate to the user device can be performed at different timings. For example, the operations up to the identity verification are performed at the store counter, and after the electronic certificate is issued. This operation can be performed in a time zone desired by the user, and can be operated without restrictions on time and place. Therefore, the convenience of installation and activation of the encryption function can be improved.
  • the setup program of the user device 30 notifies the certificate authority of the telephone number and / or IMSI of the communication SIM card together with the user identification code, and thereby the terminal of the applicant (authorized terminal). Terminal). Accordingly, even when the request for issuing the electronic certificate and the transmission to the user device are performed at different timings, it is possible to prevent an error such as erroneously transmitting the electronic certificate to another terminal. Further, since it is possible to suppress a malicious person from acquiring an electronic certificate illegally, it is possible to safely issue and transmit the electronic certificate.
  • the setup program of the user device 30 writes the electronic certificate in the memory of the IC card by using the electronic certificate writing function 626 of the IC card (step S1812).
  • personal information, a secret key, a public key, and an electronic certificate, which are data necessary for security processing, are stored in the memory of the IC card.
  • the electronic certificate may be stored in a SIM card or a secure element mounted on the user device 30.
  • the setup program of the user device 30 reads the “serial number” and “serial number” from the IC card, and also reads the “telephone number” and “IMSI” from the communication SIM card. Further, the setup program acquires "IMEI (International @ Mobile @ Equipment @ Identity)" as information of the user device itself. Then, the setup program transmits an IC card registration request together with the information to the management server of the communication service administrator. Upon receiving the IC card registration request from the user device 30, the management server registers the information of the IC card, the SIM card, and the user device included therein in the IC card management database (step S1814).
  • the management server When the registration of the IC card management information is completed, the management server notifies the user device 30 of the completion of the registration. Thus, the setup of the user device 30 is completed, and the IC card becomes usable (activated).
  • the issuing procedure shown in FIG. 19 is merely an example, and the issuing procedure may be performed in a different procedure.
  • the user identification code may be transmitted to the user equipment by data communication via the Internet instead of SMS.
  • the IP address of the user device may be specified using the IMSI of the communication SIM card.
  • biometric authentication is used instead of PIN code authentication, biometric information (face image, voiceprint, iris, fingerprint, etc.) to be registered as personal information in the IC card may be input using a procedure terminal or the like. .
  • FIG. 20 is a diagram illustrating an example of a mechanism for specifying an IC chip used in the user device when performing communication between the user device and the intermediate server.
  • the user device 30 has two IC chips 190 and 191, the IC chip 190 is used for communication with the server A192, and the IC chip 191 is used for communication with the server B193.
  • the IC chips 190 and 191 any type of IC chip may be used in addition to the above-described sub SIM type IC card, a communication SIM card, a secure element, and the like.
  • ICA unique ID is assigned to each of the IC chips 190 and 191.
  • This ID is identification information that can uniquely specify the IC chip, and is stored in the built-in memory of the IC chip.
  • the ID of the IC chip 190 is “aaa1”
  • the ID of the IC chip 191 is “bbb2”.
  • the ID may be any information as long as it does not overlap with other IC chips.
  • IMSI International Mobile Subscriber Identity
  • ICCID Integrated Circuit Card ID
  • a telephone number a serial number, a serial number, and the like
  • an IP address associated with the IMSI or the like may be used as the ID.
  • the main application 60 of the user device 30 adds the ID “aaa1” of the IC chip 190 to the header or the like of the data (communication packet) 194 to be transmitted to the server A 192 as the information of the transmission source.
  • the server A 192 can specify the IC chip 190 used in the user device 30.
  • the server A 192 also adds the ID “aaa1” of the IC chip 190 to the header or the like of the data (communication packet) 194 to be transmitted to the user device 30 as the destination information.
  • the main body application 60 can specify the IC chip 190 that is in charge of processing the data received from the server A192.
  • the main application 60 of the user device 30 adds the ID “bbb2” of the IC chip 191 to the header or the like of the data (communication packet) 195 to be transmitted to the server B 193 as the information of the transmission source.
  • the server B 193 can specify the IC chip 191 used in the user device 30.
  • the server B 193 also adds the ID “bbb2” of the IC chip 191 to the header or the like of the data (communication packet) 195 to be transmitted to the user device 30 as the destination information.
  • the main body application 60 can specify the IC chip 190 that is in charge of processing the data received from the server A192.
  • data transmission / reception is performed between the user device 30 and each server by specifying an IC chip as a transmission source or a transmission destination, so that communication security can be further improved.
  • the main application 60 uses the combination for the processing of the data 194 and 195 based on the ID information included in the header of the data 194 and 195.
  • the IC chips 190 and 191 to be selected can be selected (switched). Such an advantage is particularly great when the user device 30 includes a plurality of IC chips or when the user device 30 performs secure communication with a plurality of servers.
  • the IC chip is associated with the server by adding IC chip identification information to data transmitted and received between the user device 30 and each server. You may realize that.
  • the main body application 60 may have association information 196 (hereinafter, referred to as “correspondence table 196”) for associating an IC chip with a server.
  • the identification information of the IC chip may be associated with the identification information of the server that performs communication using the encryption function of the IC chip.
  • the identification information of the IC chip for example, an IMSI (International Mobile Subscriber Identity), an ICCID (Integrated Circuit Card ID), a telephone number, a serial number, a serial number, and an IP address associated with the IMSI may be used.
  • the server identification information for example, the server IP address, URL, or the like may be used.
  • the IC chip used in communication with the server can be specified based on the correspondence table 196. Therefore, the same effect as that of the method of FIG. 20 can be obtained.
  • the communication between the user device 30, the intermediate server 21, and the service providing server 20 is protected by a public key cryptosystem using an IC chip.
  • this method is a preferable form in that high security can be ensured, it is not essential that all communication between the three parties be performed by this method.
  • the risk of cyber attacks such as interception of communication and spoofing is relatively high, so that high security is desired. Communication between them has a relatively low risk of cyber attacks. Therefore, for example, protection using an IC chip is applied to communication between the user device 30 and the intermediate server 21, and security between the intermediate server 21 and the service providing server 20 is secured by another method. Good.
  • FIG. 22 shows the flow of the registration procedure for the intermediate service.
  • ID and password hereinafter referred to as “user ID 1” and “password 1” for convenience
  • ID and password for logging in to the service provided by the service providing server 20 hereinafter “user ID 2” for convenience
  • Password 2 is given to the user.
  • the user operates the user device 30 to download and install the main body application 60 (step S2100). Then, the user activates the main body application 60 and opens the login screen of the intermediate server 21 (Step S2101). At the first login, the user inputs the user ID 1 and the password 1 to the intermediate server 21 on the login screen, and the user device 30 transmits a login request to the intermediate server 21 together with the user ID 1 and the password 1 (step S2102). At this time, the main body application 60 stores the user ID 1 to the intermediate server 21 in the nonvolatile memory (Step S2103). It is better not to store the password 1 in the user device 30 from the viewpoint of security.
  • the user ID 1 and the password 1 to the intermediate server 21 are information given by the intermediate service provider when a new application for the intermediate service, which is a separate procedure, is made.
  • the intermediate server 21 verifies the user ID 1 and the password 1 and when the login is completed (step S2104), the intermediate server 21 transmits a predetermined electronic message (contents may be arbitrary) to the user device 30, and performs an electronic signature. And an electronic certificate (step S2105).
  • the user authentication unit 601 of the main application 60 displays a PIN code input screen.
  • the user authentication unit 601 uses the authentication function 620 of the IC chip to check whether the input PIN code is correct (step S2106).
  • the PIN code is correct (that is, when the user authentication is successful)
  • other functions of the IC chip can be used from the main body application 60.
  • the security processing unit 602 of the main body application 60 performs an electronic signature on the message received from the intermediate server 21 using the electronic signature function 622 of the IC chip, and performs an electronic signature from the memory using the electronic certificate read function 627. Read the certificate.
  • the main processing unit 600 of the main body application 60 transmits the electronic signature-attached electronic message and the electronic certificate to the intermediate server 21 (Step S2107).
  • the intermediate server 21 verifies the electronic signature-attached message using the electronic certificate received from the user device 30 (step S2108). If the verification is successful, the intermediate server 21 links the user ID1 of the user to the intermediate server 21 with the electronic certificate and registers the electronic certificate in the user information storage unit 211 (step S2109). Then, the intermediate server 21 notifies the main application 60 that registration of the electronic certificate has been completed (step S2110). When the registration with the intermediate server 21 is completed, a menu screen is displayed on the user device 30 (step S2111).
  • FIG. 23 shows a flow of login authentication of the intermediate service.
  • the user authentication unit 601 displays a PIN code input screen (step S2200).
  • the user authentication unit 601 uses the authentication function 620 of the IC chip to check whether the input PIN code is correct (step S2201). If the PIN code is correct (that is, if the user authentication is successful), the security processing unit 602 of the main application 60 uses the electronic signature function 622 of the IC chip to convert the user ID 1 to the intermediate server 21 and the authentication message. On the other hand, an electronic signature is performed (step S2202). Then, the main processing unit 600 of the main application 60 transmits a login request to the intermediate server 21 (Step S2203).
  • the login request includes a user ID 1 to the intermediate server 21, a user ID 2 and a password 2 to the service providing server 20, an authentication message, and an electronic signature.
  • the login control unit 212 of the intermediate server 21 Upon receiving the login request, the login control unit 212 of the intermediate server 21 reads the corresponding electronic certificate from the user information storage unit 211 based on the user ID 1 to the intermediate server 21 included in the login request, and Is used to verify the digital signature included in the login request (step S2204). If necessary, the login control unit 212 may inquire of the certificate authority about the validity of the electronic certificate (steps S2205 and S2206). If the verification of the electronic signature is successful and the validity of the electronic certificate is confirmed, the login control unit 212 determines that the login request is from a valid user and sends the user to the service providing server 20. The ID 2 and the password 2 are associated with the user ID 1 of the user to the intermediate server 21 and registered in the user information storage unit 211 (step S2207).
  • the login control unit 212 of the intermediate server 21 transmits an access request to the service providing server 20 (Step S2208).
  • the access request includes a user ID 2 and a password 2 for the service providing server 20.
  • the access control unit 202 of the service providing server 20 verifies the user ID 2 and the password 2 to the service providing server 20 (Step S2209). If the verification of the user ID 2 and the password 2 is successful, the access control unit 202 determines that the access request is from the intermediate server 21 to which the user has been given the proxy authority, and gives the intermediate server 21 an access permission. (Step S2210).
  • the intermediate server 21 When the access permission for the online service is obtained, the intermediate server 21 notifies the main body application 60 of the login authentication OK (step S2211). Thereafter, the menu screen of the intermediate service is displayed on the user device 30, and the user can perform a desired procedure (step S2212).
  • the intermediate service and the online service can be used with a very simple operation as compared with the method using a physical token.
  • FIG. 24 is a diagram showing a flow when using the intermediate service. It is assumed that the login to the intermediate service has already been completed and the menu screen is displayed on the user device 30.
  • step S2300 When the user selects a procedure to be used from the menu screen, the screen transits to a detailed screen (step S2300).
  • necessary information for example, transfer destination, transfer amount, etc.
  • step S2301 the main processing unit 600 of the main application 60 describes information necessary for the transfer procedure.
  • the created procedure message is created (step S2302).
  • the user authentication unit 601 of the main body application 60 displays a PIN code input screen and performs PIN code authentication (step S2303). Since the procedure of PIN code authentication is the same as that described above, the description is omitted.
  • the security processing unit 602 of the main application 60 performs an electronic signature on the procedure message using the electronic signature function 622 of the IC chip (step S2304).
  • the electronic signature function 622 may calculate a hash value of the procedure message and generate an electronic signature by encrypting the hash value with a secret key, or encrypt the procedure message itself with a secret key. Thus, an electronic signature may be generated.
  • the main processing unit 600 of the main application 60 transmits a procedure request to the intermediate server 21 (Step S2305).
  • the procedure request includes a user ID 1 for the intermediate server 21, a procedure message, and an electronic signature.
  • the proxy control unit 213 of the intermediate server 21 Upon receiving the procedure request, the proxy control unit 213 of the intermediate server 21 reads the corresponding electronic certificate from the user information storage unit 211 based on the user ID 1 of the user included in the procedure request to the intermediate server, and reads the electronic certificate. The digital signature included in the procedure request is verified using the certificate (step S2306). Further, the proxy control unit 213 may inquire of the certificate authority about the validity of the electronic certificate as necessary (steps S2307 and S2308). If the verification of the electronic signature is successful and the validity of the electronic certificate is confirmed, the proxy control unit 213 determines that the procedure request is from a valid user. That is, it is determined that there is no impersonation by a third party and that the contents of the procedure message have not been falsified.
  • the proxy control unit 213 reads out the user ID 2 and the password 2 of the user to the service providing server 20 and transmits the procedure request to the service providing server 20. (Step S2309).
  • the procedure message and the electronic signature received from the user device 30 are added to the procedure request.
  • the procedure control unit 203 of the service providing server 20 verifies the user ID 2 and the password 2 (Step S2310). If the user ID 2 and the password 2 are successfully verified, the procedure control unit 203 determines that the procedure request is from a valid user. That is, it is determined that there is no spoofing by a third party and that the content of the procedure message has not been tampered with.
  • the procedure control unit 203 executes a procedure (such as a transfer) based on the information described in the procedure message (step S2311).
  • a procedure completion notification to the intermediate server 21
  • the intermediate server 21 transmits a procedure completion notification to the main application 60 (steps S2312 and S2313). Then, a procedure completion screen is displayed.
  • the intermediate service and the online service can be used with a very simple operation as compared with a method using a physical token.
  • the procedure for registering the user's digital certificate in the intermediate server 21 (steps S2400 to S2410) is the same as the procedure (steps S2100 to S2110) described with reference to FIG.
  • an authorization code for issuing an access token and an access token are issued.
  • the access token is like a certificate when the intermediate server 21 uses the online service on behalf of the user.
  • the proxy of the online service by the intermediate server 21 is realized using the mechanism of OAuth 2.0.
  • the user device 30 sends the user ID 1 to the intermediate server 21, the user ID 2 and password 2 to the service providing server 20, a message with an electronic signature, an electronic certificate Is transmitted to the intermediate server 21 (step S2411).
  • the intermediate server 21 verifies the electronic signature-added message using the electronic certificate received from the user device 30 (step S2412).
  • the user registration unit 200 of the intermediate server 21 links the user ID 2 to the service providing server 20 and the user ID 1 to the intermediate server 21 and registers them in the user information storage unit 211 (Step S2413).
  • the intermediate server 21 transmits an authorization code issuance request to the service providing server 20 together with the user ID 2 and the password 2 to the service providing server 20 received from the user device 30 (step S2414).
  • the service providing server 20 verifies the user ID 2 and the password 2 received from the intermediate server 21, and when the verification is successful, the service providing server 20 issues an authorization code for issuing an access token associated with the received user ID 2. (Step S2415).
  • the service providing server 20 transmits the authentication result together with the user ID 2 and the authorization code to the intermediate server 21 (Step S2416).
  • the intermediate server 21 converts the received user ID 2 to the service providing server 20 into the user ID 1 to the intermediate server 21, and transmits the authorization code and the authentication result to the user device 30 (step S2417).
  • the user device 30 transmits an access token issuance request to the intermediate server 21 together with the user ID 1 and the authorization code to the intermediate server 21 (step S2418).
  • the intermediate server 21 converts the received user ID 1 to the intermediate server 21 into a user ID 2 to the service providing server 20, and transmits the user ID 2, the authorization code, and the access token issuance request to the service providing server 20 (step S2419).
  • the service providing server 20 issues an access token to the pair of the user and the intermediate service (step S2420).
  • the user registration unit 200 associates the issued access token with the user ID 2 for the service providing server 20 and registers the user ID in the user information storage unit 201.
  • the service providing server 20 transmits the user ID 2 to the service providing server 20 and the issued access token to the intermediate server 21 (Step S2421).
  • the intermediate server 21 associates the received access token with the user ID 1 of the user to the intermediate server 21 and registers it in the user information storage unit 211 (step S2422).
  • the intermediate server 21 also receives a refresh token from the service providing server 20 together with the access token.
  • the refresh token is a token used for reissuing an access token. Since this is a specification of OAuth 2.0, detailed description is omitted here.
  • the intermediate server 21 notifies the main application 60 of the notification that the issuance of the access token has been completed, and the menu screen is displayed on the user device 30 (steps S2423 and S2424).
  • FIG. 27 shows the flow of the login process to the intermediate service.
  • the processing in steps S2600 to S2606 in FIG. 27 is almost the same as the processing in steps S2200 to S2206 in FIG.
  • this example is different from the processing in FIG. 23 in that the information added to the login request is the user ID 1 to the intermediate server 21, the authentication message, and the electronic signature.
  • the intermediate server 21 After confirming the validity of the digital signature and the validity of the digital certificate, the intermediate server 21 transmits an access request to the service providing server 20 (step S2607). At this time, the intermediate server 21 reads the user ID 2 to the service providing server 20 and the access token of the online service from the user information storage unit 211 based on the user ID 1 to the intermediate server 21 included in the login request, and Send.
  • the access control unit 202 of the service providing server 20 verifies the user ID 2 and the access token for the service providing server 20 included in the access request (Step S2608). If the verification is successful, the access control unit 202 determines that the access request is from the intermediate server 21 to which the user has been given the proxy authority, and gives access permission to the intermediate server 21 (step S2609).
  • the intermediate server 21 When the online service access permission is obtained, the intermediate server 21 notifies the main body application 60 of the login authentication OK (step S2610). Thereafter, the menu screen of the intermediate service is displayed on the user device 30, and the user can perform a desired procedure (step S2611).
  • the intermediate service and the online service can be used with a very simple operation as compared with the method using a physical token.
  • FIG. 28 shows a flow of processing of the online service. Steps S2700 to S2708 in FIG. 28 are the same as steps S2300 to S2308 in FIG.
  • the proxy control unit 213 of the intermediate server 21 transmits the procedure request to the service providing server 20 (step S2709).
  • the proxy control unit 213 reads the user ID 2 to the corresponding service providing server 20 and the access token of the online service from the user information storage unit 211 based on the user ID 1 received from the user device 30, and (Step S2709).
  • the procedure request includes an access token, a procedure message received from the user device 30, and an electronic signature.
  • the procedure control unit 203 of the service providing server 20 verifies the user ID 2 and the access token to the service providing server 20 included in the procedure request (Step S2710). If the verification is successful, the procedure control unit 203 determines that the procedure request is from a valid user.
  • the procedure control unit 203 executes a procedure (such as a transfer) based on the information described in the procedure message (step S2711).
  • a procedure such as a transfer
  • the procedure control unit 203 transmits a procedure completion notification to the intermediate server 21 (Step S2712), and the intermediate server 21 transmits a procedure completion notification to the main application 60 (Step S2713).
  • the procedure completion screen is displayed on the user device 30 that has received the procedure completion notification.
  • the intermediate service and the online service can be used with a very simple operation as compared with the method using a physical token.
  • Communication between the intermediate server 21 and the service providing server 20 may be encrypted by a method different from the encrypted communication by the IC chip.
  • a common key may be shared between the intermediate server 21 and the service providing server 20, and communication between the intermediate server 21 and the service providing server 20 may be encrypted with the common key.
  • communication between the intermediate server 21 and the service providing server 20 may be encrypted by a public key cryptosystem.
  • encrypted communication such as SSL / TLS and IPsec may be used.
  • the encrypted communication of (3) may be combined with the method of using the user ID and the password of (1) or the method of using the access token of (2).
  • a secure communication between the intermediate server 21 and the service providing server 20 can be realized by using a mechanism of the dedicated line.
  • a dedicated line is a communication line that can be used exclusively.
  • a physical dedicated line may be provided between the intermediate server 21 and the service providing server 20, or a virtual dedicated line (VPN) may be used.
  • VPN virtual dedicated line
  • the dedicated line (4) may be combined with the method (1) using a user ID and password, the method (2) using an access token, or the method (3) using encrypted communication. .
  • FIG. 29A shows a configuration in which two or more intermediate servers 21A and 21B are connected (serial) between the user device 30 and the service providing server 20.
  • the first intermediate server 21A is a server of a company (referred to as a Fintech company) that provides a value-added service such as a household account book or asset management in cooperation with a bank service
  • the second intermediate server 21B is a Fintech company.
  • the service providing server 20 is a bank system that provides an online banking service by intervening between a bank and a bank to perform verification by an electronic certificate, management of a user, and the like.
  • a part or all of the processing such as the verification by the electronic certificate and the management of the user is separated from the service providing server 20 and replaced with another intermediate server 21B so that the service providing server 20 can be easily introduced and operated. Expected to be.
  • Such a form is advantageous, for example, in a case where the management of the electronic certificates and the users of the service providing servers 20 of a plurality of banks is centrally performed by one intermediate server 21B.
  • the configuration of FIG. 29A can also be applied to the case where the intermediate server 21A of a Fintech company uses the service of the intermediate server 21B of another Fintech company. For example, it is assumed that services provided by individual Fintech companies are bundled to provide an integrated Fintech service.
  • FIG. 29B shows a configuration in which two or more service providing servers 20A and 20B are connected in series. This configuration can be applied, for example, to a case where a bank transfers money to another bank, a case where a bank server and a securities server cooperate, and the like.
  • FIG. 29C is an example of a configuration in which two or more intermediate servers 21A and 21B and two or more service providing servers 20A and 20B are connected in series.
  • the number of connections between the intermediate server 21 and the service providing server 20 is arbitrary. The operation in the case where there are two intermediate servers and one service providing server will be described below.
  • FIG. 30 shows the flow of the registration procedure for the intermediate service.
  • the user registration for the intermediate service provided by the intermediate server A (21A) and the user registration for the online service provided by the service providing server 20 have already been completed, and the user logs in to the service provided by the intermediate server A.
  • ID and password hereinafter referred to as “user ID 1” and “password 1” for convenience
  • user ID 1 and “password 1” for convenience an ID and password for logging in to a service provided by the service providing server 20
  • User ID 2 ”and“ Password 2 ” are assigned to the user.
  • the intermediate server A (21A) and the intermediate server B (21B) cooperate to provide an intermediate service to the user, and the user should be aware that the intermediate server is connected in multiple stages. There is no.
  • the user operates the user device 30 to download and install the main body application 60 (step S2900). Then, the user starts the main body application 60 and opens the login screen of the intermediate server A (step S2901). At the first login, the user ID 1 and password 1 for the intermediate server A are input on the login screen, and the user device 30 transmits a login request to the intermediate server A along with the user ID 1 and password 1. At this time, the main body application stores the user ID 1 to the intermediate server A in the nonvolatile memory (Step S2903). It is better not to store the password 1 in the user device 30 from the viewpoint of security.
  • the user ID 1 and the password 1 to the intermediate server A are information given by the intermediate service provider when a new application for the intermediate service, which is a separate procedure, is made.
  • the intermediate server A verifies the user ID 1 and the password 1 and when the login to the intermediate server A is completed (step S2904), the intermediate server A transmits the user ID 1 and the password 1 received from the user device 30 to the intermediate server B. (Step S2905).
  • the intermediate server B verifies the user ID 1 and the password 1, and when the login to the intermediate server B is completed (step S2906), the intermediate server B transmits a predetermined message (contents may be any) to the intermediate server B. A, and requests an electronic signature and an electronic certificate (step S2907).
  • the intermediate server A transmits the predetermined message received from the intermediate server B to the user device 30 (Step S2908).
  • the user authentication unit 601 of the main application 60 displays a PIN code input screen.
  • the user authentication unit 601 uses the authentication function 620 of the IC chip to check whether the input PIN code is correct (step S2909).
  • the PIN code is correct (that is, when the user authentication is successful)
  • other functions of the IC chip can be used from the main body application 60.
  • the security processing unit 602 of the main body application 60 performs an electronic signature on the message received from the intermediate server A using the electronic signature function 622 of the IC chip, and performs an electronic signature from the memory using the electronic certificate read function 627. Read the certificate.
  • the main processing unit 600 of the main body application 60 transmits the electronic signature-attached electronic message and the electronic certificate to the intermediate server A (step S2910).
  • the intermediate server A transmits the electronic signature-added electronic message and the electronic certificate received from the user device 30 to the intermediate server B (step S2911), and verifies the electronic signature-added electronic message using the electronic certificate (step S2912). . If the verification is successful, the intermediate server A associates the user ID1 of the user with the electronic certificate and registers it in the user information storage unit (step S2913).
  • the intermediate server B verifies the electronic signature-attached message using the electronic certificate (step S2914). If the verification is successful, the intermediate server B associates the user ID1 of the user with the electronic certificate and registers it in the user information storage unit (step S2916). Then, the intermediate server B notifies the intermediate server A that registration of the electronic certificate has been completed (step S2916). In response, the intermediate server A notifies the main application 60 that registration of the electronic certificate has been completed (step S2917). When the registration for the intermediate service is completed, a menu screen is displayed on the user device 30.
  • FIG. 31 and FIG. 31 show the flow of login authentication of the intermediate service.
  • the user authentication unit 601 displays a PIN code input screen (step S3000).
  • the user authentication unit 601 checks whether the input PIN code is correct using the authentication function 620 of the IC chip (step S3001). If the PIN code is correct (that is, if the user authentication is successful), the security processing unit 602 of the main application 60 uses the electronic signature function 622 of the IC chip to convert the user ID 1 to the intermediate server A and the authentication message. On the other hand, an electronic signature is performed (step S3002). Then, the main processing unit 600 of the main application 60 transmits a login request to the intermediate server A (Step S3003).
  • the login request includes a user ID 1 for the intermediate server A, a user ID 2 and a password 2 for the service providing server 20, an authentication message, and an electronic signature.
  • the login control unit 212 of the intermediate server A Upon receiving the login request, the login control unit 212 of the intermediate server A reads the corresponding electronic certificate from the user information storage unit 211 based on the user ID 1 for the intermediate server A included in the login request, and Is used to verify the digital signature included in the login request (step S3004). If necessary, the login control unit 212 may inquire of the certificate authority about the validity of the electronic certificate (steps S3005 and S3006). If the verification of the electronic signature is successful and the validity of the electronic certificate is confirmed, the login control unit 212 determines that the login request is from a valid user.
  • the login control unit 212 of the intermediate server A transmits a login request to the intermediate server B (Step S3007).
  • the login request includes a user ID 1, a user ID 2, a password 2, an authentication message, and an electronic signature.
  • the login control unit 212 of the intermediate server B Upon receiving the login request, the login control unit 212 of the intermediate server B reads the corresponding electronic certificate from the user information storage unit 211 based on the user ID 1 included in the login request, and logs in using this electronic certificate. The digital signature included in the request is verified (step S3008). If necessary, the login control unit 212 may inquire of the certificate authority about the validity of the electronic certificate (steps S3009 and S3010). If the verification of the electronic signature is successful and the validity of the electronic certificate is confirmed, the login control unit 212 determines that the login request is from a valid user and sends the user to the service providing server 20. The ID 2 and the password 2 are associated with the user ID 1 of the user to the intermediate server A and registered in the user information storage unit 211 (step S3011).
  • the login control unit 212 of the intermediate server B transmits an access request to the service providing server 20 (Step S3012).
  • the access request includes a user ID 2 and a password 2 for the service providing server 20.
  • the access control unit 202 of the service providing server 20 verifies the user ID 2 and the password 2 to the service providing server 20 (Step S3013).
  • the access control unit 202 determines that the access request is from the intermediate server to which the user has been given proxy authority, and An access permission is given to B (step S3014).
  • the intermediate server B When the access permission for the online service is obtained, the intermediate server B notifies the intermediate server A of the login authentication OK (step S3015), and further, the intermediate server A notifies the main application 60 of the login authentication OK (step S3016). . Thereafter, the menu screen of the intermediate service is displayed on the user device 30, and the user can perform a desired procedure (step S3017).
  • the intermediate service and the online service can be used with a very simple operation as compared with the method using a physical token.
  • FIG. 33 and FIG. 34 are diagrams showing the flow when using the intermediate service. It is assumed that the login to the intermediate service has already been completed and the menu screen is displayed on the user device.
  • step S3200 When the user selects a procedure to be used from the menu screen, the screen transits to a detailed screen (step S3200).
  • necessary information for example, a transfer destination, a transfer amount, etc.
  • step S3201 When the user inputs necessary information (for example, a transfer destination, a transfer amount, etc.) on this detailed screen and presses an execution button (step S3201), the main processing unit 600 of the main application 60 describes information necessary for the transfer procedure.
  • the created procedure message is created (step S3202).
  • the user authentication unit 601 of the main body application 60 displays a PIN code input screen and performs PIN code authentication (step S3203). Since the procedure of PIN code authentication is the same as that described above, the description is omitted.
  • the security processing unit 602 of the main application 60 performs an electronic signature on the procedure message using the electronic signature function 622 of the IC chip (step S3204).
  • the electronic signature function 622 may calculate a hash value of the procedure message and generate an electronic signature by encrypting the hash value with a secret key, or encrypt the procedure message itself with a secret key. Thus, an electronic signature may be generated.
  • the main processing unit 600 of the main application 60 transmits a procedure request to the intermediate server A (Step S3205).
  • the procedure request includes a user ID 1 for the intermediate server A, a procedure message, and an electronic signature.
  • the proxy control unit 213 of the intermediate server A Upon receiving the procedure request, the proxy control unit 213 of the intermediate server A reads the corresponding electronic certificate from the user information storage unit 211 based on the user ID 1 of the user included in the procedure request to the intermediate server, and reads the electronic certificate. The electronic signature included in the procedure request is verified using the certificate (step S3206). If necessary, the proxy control unit 213 of the intermediate server A may inquire of the certificate authority about the validity of the electronic certificate (steps S3207, S3208). If the verification of the electronic signature is successful and the validity of the electronic certificate is confirmed, the proxy control unit 213 of the intermediate server A determines that the procedure request is from a valid user. That is, it is determined that there is no impersonation by a third party and that the contents of the procedure message have not been falsified.
  • the proxy control unit 213 of the intermediate server A transmits the procedure request to the intermediate server B (step S3209).
  • This procedure request has a user ID 1, a procedure message, and an electronic signature added thereto.
  • the proxy control unit 213 of the intermediate server B Upon receiving the procedure request, the proxy control unit 213 of the intermediate server B reads the corresponding electronic certificate from the user information storage unit 211 based on the user ID 1 included in the procedure request, and uses this electronic certificate to perform the procedure. The digital signature included in the request is verified (step S3210). If necessary, the proxy control unit 213 of the intermediate server B may inquire of the certificate authority about the validity of the electronic certificate (steps S3211 and S3212). If the verification of the electronic signature is successful and the validity of the electronic certificate is confirmed, the proxy control unit 213 of the intermediate server B determines that the procedure request is from a valid user. That is, it is determined that there is no impersonation by a third party and that the contents of the procedure message have not been falsified.
  • the proxy control unit 213 of the intermediate server B reads out the user ID 2 and the password 2 to the service providing server 20 and transmits the procedure request to the service providing server 20. (Step S3213).
  • the procedure message and the electronic signature received from the user device 30 are added to the procedure request.
  • the procedure control unit 203 of the service providing server 20 verifies the user ID 2 and the password 2 (Step S3214). If the user ID 2 and the password 2 are successfully verified, the procedure control unit 203 determines that the procedure request is from a valid user. That is, it is determined that there is no spoofing by a third party and that the content of the procedure message has not been tampered with.
  • the procedure control unit 203 executes a procedure (such as a transfer) based on the information described in the procedure message (step S3215).
  • a procedure such as a transfer
  • the procedure control unit 203 transmits a procedure completion notification to the intermediate server B (step S3216), and the intermediate server B transmits a procedure completion notification to the intermediate server A (step S3217).
  • the notification is transmitted to the main body application 60 (step S3218). Then, a procedure completion screen is displayed.
  • the user device 30 when the user device 30 performs data communication with each server or certificate authority via the Internet, the user device 30 associates the IMSI of the communication SIM card provided in the user device 30 with the IMSI.
  • the SIM card (that is, the user device 30) as the source or destination of the data is specified by the assigned IP address.
  • the IP address may be a dynamically assigned IP address or a fixed IP address.
  • Service providing server 21 Intermediate server 30: User equipment 60: Application program 70: IC card issuing terminal 306: SIM card 307: IC card (sub SIM) 308: SIM card slot

Abstract

ユーザがアプリから振込などの手続を行おうとすると、まず、ＰＩＮコードなどによるユーザ認証が要求される。ユーザ認証に成功すると、ＩＣチップの機能制限が解除され、ＩＣチップが提供する機能を利用可能なモードとなる。アプリは、ＩＣチップの機能を利用して、手続内容が記述された手続メッセージを秘密鍵で暗号化し電子署名を生成する。この電子署名と手続メッセージが中間サーバを介してオンラインサービスのサーバへと転送される。サーバは、手続メッセージの内容に従い振込などの手続を実行する。

Description

オンラインサービス提供システム、アプリケーションプログラム
　本発明は、携帯機器からオンラインサービスを利用する際のセキュリティを向上する技術に関する。
　インターネットの普及により多種多様なオンラインサービスが登場し、多くの人々に利用されている。一方で、サイバーセキュリティ問題は日増しに増大しているため、安心・安全にオンラインサービスを利用するためのセキュリティ対策が求められている。
　例えば、オンラインバンキングサービスにおいては、昨今、中間者攻撃（ＭＩＴＭ：Man In The Middle）と呼ばれるサイバー攻撃による被害が急増している。ＭＩＴＭ攻撃は、マルウェアや偽サイトを使って、オンラインバンキングの利用者と金融機関との間の通信を乗っ取り（通信内容を改ざんし）、利用者と金融機関の双方に気づかれることなく不正な送金処理などを行う攻撃手法である。ＭＩＴＢ（Man In The Browser）もＭＩＴＭの一種である。なお、ＡＴＭ網を利用した送金処理は古くから行なわれていたが、従来は専用線を利用していたためサイバー攻撃のリスクは極めて低かった。これに対し、インターネットのようなオープンなネットワークを利用するオンラインサービスは、ＭＩＴＭ攻撃のような様々な脅威に晒されるのである。
　現在のオンラインバンキングサービスでは、セキュリティ対策として、ワンタイムパスワード発行器を利用する方法が広く用いられている。これは、サービス利用者にあらかじめワンタイムパスワード発行器を配布しておき、サービスへのログイン時や送金処理を行う際などに、ワンタイムパスワード発行器で生成・表示されるワンタイムパスワードを使って認証を行うという方法である（特許文献１参照）。しかしこの方法は、ＭＩＴＭ攻撃に対しては効果がない。ＭＩＴＭ攻撃の一種であるＭＩＴＢ攻撃では、マルウェアや偽サイトによりログインＩＤやワンタイムパスワードなどの認証情報を利用者自身に入力させ、それらの認証情報をそのまま使って利用者へのなりすましを行うからである。
　そこで最近では、ＭＩＴＭ攻撃への対策として「トランザクション認証」と呼ばれる対策をとる金融機関が増えてきている。トランザクション認証は、一般的に、利用者とサーバの間のトランザクションの暗号化（電子署名）と、ブラウザとは別経路のセッションを利用したトランザクション内容の確認との組み合わせにより実現される。トランザクション内容の確認には、トークンと呼ばれる専用のデバイスが利用されることが多い（特許文献２参照）。
特開２０１６－０７１５３８号公報 特開２０１２－０４８７２８号公報
　トランザクション認証は、利用者とサーバの間のトランザクションに電子署名を行うため、ＭＩＴＭ攻撃には有効な対策である。しかしながら、現在主流であるハードウェアトークンを用いる方法はいくつかの課題が指摘されている。一つは、ユーザにとっての利便性の低さである。スマートフォンやタブレット端末などの携帯機器（モバイルデバイス）でオンラインサービスを利用することを想定した場合、ユーザは外出先に常にトークンを携帯しなければならず面倒である。しかも、サービスごとにトークンが異なるため、利用するサービスが増えるほど携帯するトークンの数も増えてしまい、実用性に欠ける。さらに、盗難や紛失のリスクを考慮すると、トークンを持ち歩くことに抵抗を感じる人も多い。二つ目は、サービス提供者の負担コストである。サービス提供者は、オンラインサービスの利用者全員にトークンを配布し管理する必要があり、そのコストは無視できない。
　また、銀行法改正（２０１８年６月施行）を受けて、各金融機関が、口座管理や電子送金などを代行する電子決済等代行業者に対して、ＡＰＩ（Application Programming Interface）を開放する動きが進んでいる。したがって、今後は、金融機関とユーザの２者間のセキュリティだけでなく、金融機関（オンラインサービスの提供者）と電子決済等代行業者（中間サービスの提供者）とユーザの３者間のセキュリティを確保する必要が出てくる。
　本発明は上記実情に鑑みなされたものであって、モバイルの利便性を損なうことなく、セキュアなサービス利用を実現可能な、新たなセキュリティ技術を提供することを目的とする。また、本発明のさらなる目的は、オンラインサービスの提供者と中間サービスの提供者とユーザの３者間の高度なセキュリティを確保することのできる、新たなセキュリティ技術を提供することにある。
　本発明の第一側面は、
　サービス提供者が提供するオンラインサービスを、前記サービス提供者とは異なる者が提供する中間サービスを介して、携帯機器から安全に利用可能な仕組みを提供するオンラインサービス提供システムであって、
　登録されたユーザに対し、インターネットを通じて前記オンラインサービスを提供するサービス提供サーバと、
　前記ユーザに対し、インターネットを通じて前記中間サービスを提供する中間サーバと、
　前記ユーザが所持している携帯機器であるユーザ機器に設けられるＩＣチップと、
　前記ユーザ機器が有する本体プロセッサにより実行され、前記ユーザ機器を前記中間サービスを利用するための端末として機能させるアプリケーションプログラムと、を有し、
　前記ＩＣチップは、
　　少なくとも、前記ユーザ機器を使用する者の正当性を確認するためのユーザ認証に用いられる本人情報、前記ユーザの秘密鍵、前記秘密鍵とペアになる前記ユーザの公開鍵、及び、前記公開鍵を含む前記ユーザの電子証明書を非一時的に記憶するメモリと、
　　少なくとも、前記アプリケーションプログラムから与えられる情報を前記本人情報と照合することにより前記ユーザ認証を行う認証機能、及び、前記アプリケーションプログラムから与えられるデータに対し前記秘密鍵を用いた電子署名を行う電子署名機能を有するプロセッサと、
を有しており、
　前記アプリケーションプログラムは、前記ユーザ機器を、
　　前記ユーザ機器を使用する者から取得した情報に基づき、前記ＩＣチップの前記認証機能を利用して、前記ユーザ認証を行うユーザ認証手段、及び、
　　前記ユーザ認証により前記ユーザ機器を使用する者が正当であると確認された場合に、前記ＩＣチップの前記電子署名機能を利用して電子署名を生成し、生成された前記電子署名を含むログイン要求をインターネットを通じて前記中間サーバに送信する送信手段、として機能させ、
　前記中間サーバは、
　　前記ユーザに関する情報として、前記ユーザの電子証明書を記憶するユーザ情報記憶手段と、
　　前記ユーザ機器から前記ログイン要求を受信した場合に、前記ユーザの電子証明書を用いて前記ログイン要求に含まれる前記電子署名を検証することによって前記ログイン要求の正当性を確認し、前記ログイン要求が正当であると確認された場合に前記ユーザ機器からの前記中間サービスの利用を許可すると共に、前記ログイン要求に含まれる前記電子署名を含むアクセス要求をインターネットを通じて前記サービス提供サーバに送信する制御手段と、
を有し、
　前記サービス提供サーバは、
　　前記ユーザに関する情報として、前記ユーザの電子証明書を記憶するユーザ情報記憶手段と、
　　前記中間サーバから前記アクセス要求を受信した場合に、前記ユーザの電子証明書を用いて前記アクセス要求に含まれる前記電子署名を検証することによって前記アクセス要求の正当性を確認し、前記アクセス要求が正当であると確認された場合に前記中間サーバが前記ユーザの代わりに前記オンラインサービスを利用することを許可するアクセス制御手段と、
を有することを特徴とするオンラインサービス提供システムを提供する。
　本発明の第二側面は、
　ユーザが所持している携帯機器であるユーザ機器が有する本体プロセッサにより実行され、前記ユーザ機器を、サービス提供サーバがインターネットを通じて提供するオンラインサービスを前記サービス提供サーバとは異なる中間サーバが提供する中間サービスを介して利用するための端末として機能させるアプリケーションプログラムであって、
　前記ユーザ機器には、
　　少なくとも、前記ユーザ機器を使用する者の正当性を確認するためのユーザ認証に用いられる本人情報、前記ユーザの秘密鍵、前記秘密鍵とペアになる前記ユーザの公開鍵、及び、前記公開鍵を含む前記ユーザの電子証明書を非一時的に記憶するメモリと、
　　少なくとも、前記アプリケーションプログラムから与えられる情報を前記本人情報と照合することにより前記ユーザ認証を行う認証機能、及び、前記アプリケーションプログラムから与えられるデータに対し前記秘密鍵を用いた電子署名を行う電子署名機能を有するプロセッサと、
を有するＩＣチップが設けられており、
　前記アプリケーションプログラムは、前記ユーザ機器を、
　　前記ユーザ機器を使用する者から取得した情報に基づき、前記ＩＣチップの前記認証機能を利用して、前記ユーザ認証を行うユーザ認証手段、及び、
　　前記ユーザ認証により前記ユーザ機器を使用する者が正当であると確認された場合に、前記ＩＣチップの前記電子署名機能を利用して電子署名を生成し、生成された前記電子署名を含むログイン要求をインターネットを通じて前記中間サーバに送信する送信手段、として機能させることを特徴とするアプリケーションプログラムを提供する。
　本発明は、上記のサービス提供サーバ、又は、中間サーバ、又は、上記のＩＣチップとアプリケーションプログラムを備える携帯機器、又は、上記の処理の少なくとも一部を含むオンラインサービス提供方法、又は、上記のＩＣチップとアプリケーションプログラムによる処理の少なくとも一部を含む携帯機器の制御方法、又は、上記のアプリケーションプログラムを非一時的に記憶したコンピュータ読取可能な記憶媒体、として捉えることもできる。
　本発明によれば、モバイルの利便性を損なうことなく、セキュアなサービス利用を実現可能な、新たなセキュリティ技術を提供することができる。また、本発明によれば、オンラインサービスの提供者と中間サービスの提供者とユーザの３者間の高度なセキュリティを確保することのできる、新たなセキュリティ技術を提供することができる。
図１は、本発明に係るオンラインサービス提供システムの特徴の一つを示す図である。 図２は、オンラインサービスを提供するサービス提供サーバの構成を示すブロック図である。 図３は、オンラインサービスを利用するために使用するユーザ機器の構成を示すブロック図である。 図４は、ＳＩＭカードとＩＣカードの外観及び装着形態を模式的に示す図である。 図５は、ＳＩＭカードとＩＣカードのハードウェア構成を模式的に示すブロック図である。 図６は、ユーザ機器とＩＣカードの論理的な構成を模式的に示すブロック図である。 図７は、ＩＣカードの発行手続を説明する図である。 図８は、ＩＣカードの発行手続を説明する図である。 図９は、ＩＣカード管理データベースのデータ構造を示す図である。 図１０は、中間サービスへの登録手続の流れを示す図である。 図１１は、中間サービスへの登録手続の流れ（図１０の続き）を示す図である。 図１２は、中間サービスへの登録手続においてユーザ機器に表示される画面例である。 図１３は、中間サービスのログイン認証の流れを示す図である。 図１４は、中間サービスのログイン認証においてユーザ機器に表示される画面例である。 図１５は、中間サービスの利用時の流れを示す図である。 図１６は、中間サービスの利用時にユーザ機器に表示される画面例である。 図１７は、セキュアエレメントを内蔵するユーザ機器のハードウェア構成を模式的に示すブロック図である。 図１８は、ＳＩＭカードを備えるユーザ機器のハードウェア構成を模式的に示すブロック図である。 図１９は、電子証明書のポストインストールを説明する図である。 図２０は、ユーザ機器と中間サーバ又はサービス提供サーバとの間で通信を行う際に、ユーザ機器において利用されるＩＣチップを特定するための仕組みの一例を示す図である。 図２１は、ユーザ機器と中間サーバ又はサービス提供サーバとの間で通信を行う際に、ユーザ機器において利用されるＩＣチップを特定するための仕組みの一例を示す図である。 図２２は、中間サービスへの登録手続の流れを示す図である。 図２３は、中間サービスのログイン認証の流れを示す図である。 図２４は、中間サービスの利用時の流れを示す図である。 図２５は、中間サービスへの登録手続の流れを示す図である。 図２６は、中間サービスへの登録手続の流れを示す図である。 図２７は、中間サービスのログイン認証の流れを示す図である。 図２８は、中間サービスの利用時の流れを示す図である。 図２９Ａ～図２９Ｃは、サーバの多段接続の例を示す図である。 図３０は、中間サービスへの登録手続の流れを示す図である。 図３１は、中間サービスのログイン認証の流れを示す図である。 図３２は、中間サービスのログイン認証の流れを示す図である。 図３３は、中間サービスの利用時の流れを示す図である。 図３４は、中間サービスの利用時の流れを示す図である。
　＜オンラインサービス提供システムの概要＞
　図１は、本発明に係るオンラインサービス提供システムの特徴の一つである、サブＳＩＭと呼ばれるＩＣカードを利用した公開鍵暗号による手続内容署名（トランザクション署名）の流れを示している。図１において、サービス提供者は、インターネットを通じてオンラインサービスを提供する者であり、例えば、オンラインバンキングサービスを提供する銀行などが該当する。中間サービス提供者は、サービス提供者が提供するオンラインサービスを代行（仲介）するサービス（本明細書では、これを「中間サービス」又は「代行サービス」と称す）を提供する者であり、例えば、口座管理や電子送金や収支管理などのＷＥＢサービスを提供する電子決済等代行業者などが該当する。
　ユーザが所持するユーザ機器（スマートフォンなど）には、中間サービスを利用するためのアプリケーションプログラム（以下「アプリ（ＡＰＰ）」とも称す）がインストールされていると共に、サブＳＩＭと呼ばれるＩＣカードが装着されている。サブＳＩＭには、当該ユーザ固有の秘密鍵が格納されている。なお、日本国内で本サービスを実施する場合、秘密鍵のペアとなる公開鍵については、電子署名及び認証業務に関する法律（平成１２年法律第１０２号。以下、「電子署名法」という。）に基づく認定を受けている認証局に事前に登録され、認証局より電子証明書が発行されているものとする。
　上記システムにおいて、ユーザがアプリから振込などの手続を行おうとすると、まず、ＰＩＮコード、パスワード、又は生体認証などによるユーザ認証（本人認証）が要求される。ユーザ認証に成功すると（つまり、アプリを操作している者がユーザ本人であることが確認されると）、サブＳＩＭの機能制限が解除され、サブＳＩＭが提供する機能を利用可能なモードとなる。アプリは、サブＳＩＭの機能を利用して、手続内容が記述された手続メッセージ（トランザクション）を秘密鍵で暗号化し電子署名を生成する。この電子署名と手続メッセージを中間サービスの中間サーバに送ると、該中間サーバが、対応する電子証明書を用いて電子署名の検証を行う。検証の結果、正当なユーザから送られてきた手続メッセージであり、かつ、内容が改ざんされていないことが確認されると、中間サーバは、電子署名と手続メッセージをオンラインサービスのサーバに転送する。すると、該サーバが、対応する電子証明書を用いて電子署名の検証を行い、正当なユーザから送られてきた手続メッセージであり、かつ、内容が改ざんされていないことが確認されると、手続メッセージの内容に従い振込などの手続を実行する。
　このような方法によれば、「サービス提供者」と「中間サービス提供者」と「ユーザ」の３者の間で、公開鍵暗号を用いた高度なセキュリティを実現することができる。この方法は、ユーザ機器以外のデバイス（従来のトークンのようなもの）を持ち歩く必要がなく、ユーザ機器単体で中間サービスを介したオンラインサービスの利用を可能とするため、利便性が高い。また、本人認証だけで電子署名を用いたセキュアな手続が可能なため、スマートかつ簡便な操作性を実現できる。
　さらに、サブＳＩＭと呼ばれるＩＣカードに格納された秘密鍵と、ＩＣカードが提供する暗号化機能を利用するため、セキュアなデータ通信を実現できる。この秘密鍵は漏えいのリスクが小さく、また、ＰＩＮコードやパスワードや生体認証による本人認証をクリアしなければ秘密鍵や暗号化機能を利用することもできないので、第三者による不正利用のリスクを可及的に小さくできる。
　また、サービス提供者にとっては、トークンのようなデバイスを配布したり管理したりする必要がなくなり、運用コストの低減を期待できる。また電子署名法に基づく認定を受けている認証局が発行した電子証明書を利用して電子署名が付されたデータは、電子署名法第３条により、ユーザ本人が真正に作成したものと推定されるため、訴訟リスクを低減できるという利点もある。
　＜中間サーバ＞
　図２Ａは、中間サーバの構成を示すブロック図である。中間サーバ２１は、中間サービス提供者による中間サービスをインターネットを通じて提供するサーバである。以下、銀行などの金融機関によるオンラインでの金融取引サービス（いわゆるオンラインバンキング）の各種手続を代行する中間サービスを例にとり、中間サーバ２１の説明を行うが、これはあくまで一つの適用例にすぎず、本発明はあらゆる種類の中間サービスに好ましく適用可能である。
　中間サーバ２１は、主な機能として、ユーザ登録部２１０、ユーザ情報記憶部２１１、ログイン制御部２１２、代行制御部２１３を有する。ユーザ登録部２１０は、ユーザの新規登録処理を行う機能である。ユーザ情報記憶部２１１は、登録されたユーザの情報を記憶・管理するデータベースである。ログイン制御部２１２は、ユーザからのログイン要求に応答して中間サービスの利用の可否及びオンラインサービスのアクセスの可否を制御する機能である。代行制御部２１３は、ユーザからの手続要求に応答してオンラインサービスの該当手続の代行を制御する機能である。これらの機能及びその処理の詳細は後述する。
　中間サーバ２１は、例えば、ＣＰＵ（プロセッサ）、メモリ（ＲＡＭ）、ストレージ（ＨＤＤ、ＳＳＤなど）、通信Ｉ／Ｆ、入出力装置などを備えた汎用のコンピュータにより構成することができる。その場合、上述した機能及びその処理は、ストレージに格納されたプログラムをメモリに展開し、ＣＰＵがプログラムを実行することによって実現される。なお、中間サーバ２１は、１台のコンピュータで構成してもよいし、分散コンピューティングやクラウドコンピューティングにより構成してもよい。また、汎用のコンピュータではなく、専用のコンピュータにより構成してもよいし、上述した機能又はその処理の一部をソフトウェアではなくＡＳＩＣやＦＰＧＡなどで構成してもよい。
　＜サービス提供サーバ＞
　図２Ｂは、サービス提供サーバの構成を示すブロック図である。サービス提供サーバ２０は、サービス提供者によるオンラインサービス（ＷＥＢサービス）をインターネットを通じて提供するサーバである。以下、銀行などの金融機関によるオンラインでの金融取引サービス（いわゆるオンラインバンキング）を例にとり、サービス提供サーバ２０の説明を行うが、これはあくまで一つの適用例にすぎず、本発明はあらゆる種類のオンラインサービスに好ましく適用可能である。
　サービス提供サーバ２０は、主な機能として、ユーザ登録部２００、ユーザ情報記憶部２０１、アクセス制御部２０２、手続制御部２０３を有する。ユーザ登録部２００は、ユーザの新規登録処理を行う機能である。ユーザ情報記憶部２０１は、登録されたユーザの情報を記憶・管理するデータベースである。アクセス制御部２０２は、中間サーバ２１からのアクセス要求に応答してオンラインサービスのアクセスの可否を制御する機能である。手続制御部２０３は、中間サーバ２１からの手続要求に応答してオンラインサービスの該当手続の実行を制御する機能である。これらの機能及びその処理の詳細は後述する。
　サービス提供サーバ２０は、例えば、ＣＰＵ（プロセッサ）、メモリ（ＲＡＭ）、ストレージ（ＨＤＤ、ＳＳＤなど）、通信Ｉ／Ｆ、入出力装置などを備えた汎用のコンピュータにより構成することができる。その場合、上述した機能及びその処理は、ストレージに格納されたプログラムをメモリに展開し、ＣＰＵがプログラムを実行することによって実現される。なお、サービス提供サーバ２０は、１台のコンピュータで構成してもよいし、分散コンピューティングやクラウドコンピューティングにより構成してもよい。また、汎用のコンピュータではなく、専用のコンピュータにより構成してもよいし、上述した機能又はその処理の一部をソフトウェアではなくＡＳＩＣやＦＰＧＡなどで構成してもよい。
　＜ユーザ機器＞
　図３は、ユーザが中間サービスを利用するために使用する携帯機器（「ユーザ機器」と称す）の構成を示すブロック図である。本実施形態では、ユーザ機器３０の一例としてスマートフォンを例示するが、これはあくまで一つの適用例にすぎない。ユーザ機器３０としては、中間サービスを利用するためのアプリケーションプログラムを実行するためのプロセッサとメモリを有し、ＳＩＭカード（Subscriber Identity Module Card）が装着され、かつ、インターネットとの接続が可能な携帯型の電子機器であればいかなるデバイスを用いてもよい。スマートフォンの他、例えば、タブレット端末、モバイルＰＣ、ウェアラブルＰＣ、スマートウォッチ、スマートグラス、スマートウォレット、携帯ゲーム機などを例示できる。
　ユーザ機器３０は、主なハードウェア資源として、ＣＰＵ（プロセッサ）３００、メモリ３０１、ストレージ３０２、タッチパネルディスプレイ３０３、通信モジュール３０４、電源３０５、ＳＩＭカード３０６、ＩＣカード３０７、ＮＦＣチップ３２０を有する。メモリ３０１はＲＡＭであり、ＣＰＵ３００がワーキングメモリとして使用する記憶領域を提供する。ストレージ３０２はアプリケーションプログラムや各種のデータを格納するための不揮発性の記憶媒体であり、例えば、内蔵のＥＥＰＲＯＭ、カードスロットに装着されるフラッシュメモリなどが該当する。タッチパネルディスプレイ３０３は、表示装置と入力装置を兼ねたデバイスである。通信モジュール３０４は、ユーザ機器３０によるデータ通信や音声通信を担うデバイスである。本実施形態の通信モジュール３０４は、３Ｇや４Ｇ／ＬＴＥなどの携帯電話網を利用した通信、Ｗｉ－Ｆｉによる通信、近距離無線通信などに対応しているものとする。電源３０５は、ユーザ機器３０に対し電力を供給するものであり、リチウムイオンバッテリと電源回路から構成される。ＳＩＭカード３０６は、携帯電話網を利用した通信の加入者情報が記録された接触型のＩＣカードである。ＩＣカード３０７も、ＳＩＭカード３０６と同じく接触型のＩＣカードである。ＩＣカード３０７は、中間サービス及びオンラインサービスのセキュアな利用を実現するためにユーザ機器３０に付加的に装着されたデバイスである。ＮＦＣチップ３２０は、ＮＦＣ（Near Field Communication）規格の近距離無線通信機能とそれを利用したアプリケーションを提供するＩＣチップである。なお、本実施形態では、ＳＩＭカード３０６、ＩＣカード３０７、ＮＦＣチップ３２０を別のハードウェアで構成したが、ＳＩＭカード３０６及び／又はＩＣカード３０７にＮＦＣの機能を搭載してもよい。
　＜ＩＣカード＞
　図４は、ＳＩＭカード３０６とＩＣカード３０７の外観及び装着形態を模式的に示し、図５は、ＳＩＭカード３０６とＩＣカード３０７のハードウェア構成を模式的に示すブロック図である。
　ＳＩＭカード３０６は、幅１５ｍｍ×高さ１２ｍｍ×厚み０．７６ｍｍの樹脂プレート上にＩＣチップ４０が実装された構造を有する。図５に示すように、ＩＣチップ４０は、プロセッサ４０１、ＲＡＭ４０２、不揮発性メモリ４０３、及び、８つのピン（電極）４０４を有する。不揮発性メモリ４０３には、ＳＩＭカード３０６のユニークなシリアルナンバー（ＩＣＣＩＤ）、加入者識別情報（ＩＭＳＩ）などのデータと、プロセッサ４０１で実行されるプログラムとが格納されている。８つのピン４０４は、電源入力端子、リセット端子、クロック端子、アース端子、プログラム用電圧入力端子、Ｉ／Ｏ端子、予備端子を含む。
　ＳＩＭカード３０６は、ユーザが移動体通信事業者（ＭＮＯ）又は仮想移動体通信事業者（ＭＶＮＯ）の提供する移動通信サービスに加入したときに、その事業者から提供されるものである。ＳＩＭカード３０６に格納されるデータやプログラムは事業者ごとに相違しているが、ＳＩＭカード３０６自体の基本的な構造は国際規格に準拠している限りにおいて同一である。なお、本実施形態では、ｍｉｃｒｏ－ＳＩＭを例に挙げたが、ＳＩＭカードとしてはｍｉｎｉ－ＳＩＭやｎａｎｏ－ＳＩＭを用いることもできる。
　ＩＣカード３０７は、幅と高さがＳＩＭカード３０６と同じ又は略同じサイズであり、厚みが約０．１～０．２ｍｍ程度の可撓性フィルムにＩＣチップ４１が埋め込まれた構造を有する。ＩＣチップ４１も、プロセッサ４１１、ＲＡＭ４１２、不揮発性メモリ４１３、及び、８つのピン（電極）４１４を有している。ＩＣカード３０７の不揮発性メモリ４１３には、オンラインサービスのセキュアな利用を実現するためのデータ及びプログラムが格納される（詳細は後述する）。
　ＩＣカード３０７の８つのピン４１４は、ＩＣカード３０７の表面と裏面の両方に露出しており、かつ、ＳＩＭカード３０６の８つのピン４０４と同じ配列になっている。図４に示すように、このＩＣカード３０７をＳＩＭカード３０６に重ねて貼り付けることにより、ＩＣカード３０７とＳＩＭカード３０６の対応するピン（電極）同士が物理的・電気的に接続されることとなる。ＩＣカード３０７は極めて薄いため、ＩＣカード３０７を貼り付けた状態のＳＩＭカード３０６をユーザ機器３０のＳＩＭカードスロット３０８に装着することが可能である。図５は、ＩＣカード３０７とＳＩＭカード３０６がＳＩＭカードスロット３０８に装着された状態を模式的に示している。ＩＣカード３０７の表面のピン４１４がユーザ機器３０の制御基板３０９の端子３１０に接続され、ＳＩＭカード３０６のピン４０４はＩＣカード３０７のピン４１４を介して制御基板３０９の端子３１０に接続されることとなる。
　ユーザ機器３０のＣＰＵ３００は、ＩＣカード３０７とＳＩＭカード３０６のいずれに対しても選択的にアクセスすることができる。言い換えると、ユーザ機器３０のＣＰＵ３００で動作するアプリケーションプログラムは、ＩＣカード３０７と通信を行うモードとＳＩＭカード３０６と通信を行うモードを選択的に切り替えることができる。前者のモードの場合、ＩＣカード３０７のプロセッサ４１１は、ユーザ機器３０から受信した信号（命令）を自身で処理し、ＳＩＭカード３０６には伝送しない。他方、後者のモードの場合は、ＩＣカード３０７のプロセッサ４１１は、ユーザ機器３０とＳＩＭカード３０６の間の信号を仲介する（スルーする）動作を行う。本実施形態のように、通信用のＳＩＭカード３０６に重ね貼りするタイプのＩＣカード３０７は「サブＳＩＭ」とも呼ばれる。
　サブＳＩＭタイプのＩＣカード３０７を用いることにより、次のようなメリットがある。ＳＩＭカードスロットを有する携帯機器であれば、ＩＣカード３０７の装着が可能である（すなわち、携帯機器側に特別な構造や細工が一切不要であり、ほとんど全ての携帯機器にＩＣカード３０７の装着が可能である）。ＳＩＭカードスロットが１つしかない携帯機器に対しても（言い換えると、ＳＩＭカードスロットの空きが無い場合でも）、ＩＣカード３０７を装着可能である。また、通信用のＳＩＭカード３０６とＩＣカード３０７とは機能的には完全に独立しており、互いに影響を与えることが無いため、ＩＣカード３０７を装着した後も音声通信やデータ通信をこれまで同様利用することができる。しかも、どの事業者のＳＩＭカードに対しても追加可能であるため、導入・普及が容易である。
　＜ＩＣカードの機能＞
　図６は、ユーザ機器３０とＩＣカード３０７の論理的な構成を模式的に示すブロック図である。
　ユーザ機器３０には、中間サーバ２１が提供する中間サービスを利用するためのアプリケーションプログラム６０（以下単に「本体アプリ６０」と称す）がインストールされている。この本体アプリ６０は、中間サービス提供者（本実施形態の場合は電子決済等代行業者など）により配布されるプログラムであり、ユーザは中間サービスの利用に先立ちインターネット上のアプリケーションディストリビュータを通じて本体アプリ６０をダウンロードしインストールする。
　本体アプリ６０は、主な機能として、メイン処理部６００、ユーザ認証部６０１、セキュリティ処理部６０２を有している。メイン処理部６００は、中間サービスの利用画面の表示や入力の制御、中間サーバ２１とのデータ送受信などを担う機能である。ユーザ認証部６０１は、ユーザ機器３０を使用する者の正当性を確認する処理を担う機能である。ここでのユーザ認証は、ユーザ機器３０を現に操作している者が正当な者（ユーザ本人、あるいは、正当なユーザから許可を受けている者）かどうかを確認することが目的である。セキュリティ処理部６０２は、ＩＣカード３０７の機能を利用してデータの暗号化や電子署名などのセキュリティ処理を実行する機能である。
　ＩＣカード３０７の不揮発性メモリ４１３（以下単に「メモリ４１３」と称す）には、上述したユーザ認証に用いられる本人情報６１０、ユーザの秘密鍵６１１と公開鍵６１２のペア、ユーザの電子証明書６１３、ハッシュ関数６１４、プログラム６１５などが格納されている。メモリ４１３のアドレス空間は、外部からのアクセス（読み書き）が可能なエリア４１３０と、外部からのアクセスが不可能なエリア（つまりＩＣカード３０７のプロセッサ４１１しかアクセスできないエリア）４１３１とを有している。セキュリティ処理で用いるデータ（本人情報６１０、秘密鍵６１１、公開鍵６１２、電子証明書６１３、ハッシュ関数６１４、プログラム６１５など）はいずれもエリア４１３１内に格納され、外部（例えば本体アプリ６０など）からは直接に読み書きできないようになっている。ＩＣカード３０７のシリアル番号６１６、製造番号６１７などのデータはエリア４１３０内に格納され、外部から読み出し可能となっている。
　ＩＣカード３０７のプロセッサ４１１は、外部のアプリに対して、セキュリティ機能に関するいくつかのＡＰＩ（Application Programming Interface）を提供する。図６では、一例として、認証機能６２０、暗号化機能６２１、電子署名機能６２２、本人情報変更機能６２３、鍵生成機能６２４、公開鍵読出機能６２５、電子証明書書込機能６２６、電子証明書読出機能６２７を示している。これらの機能は、プロセッサ４１１がプログラム６１５を実行することによって実現されるものである。
　認証機能６２０は、外部から与えられる情報を、メモリ４１３に格納されている本人情報６１０と照合することにより、ユーザ認証を行う機能である。認証機能６２０以外の機能６２１～６２７は、ユーザ認証に成功しなければ利用できないようになっている。ユーザ認証の方法は何でもよい。例えばＰＩＮコード認証であれば、認証機能６２０は、本体アプリ６０のユーザ認証部６０１からユーザの入力したコード（例えば４ケタの数字）を受け取り、その入力コードが本人情報６１０として登録されているＰＩＮコードと一致するか確認し、一致していれば「ＯＫ」、一致していなければ「ＮＧ」という結果を返す。パスワード認証であれば、認証機能６２０は、本体アプリ６０のユーザ認証部６０１からユーザの入力したパスワード（例えば６～１６文字のパスワード）を受け取り、その入力パスワードが本人情報６１０として登録されているパスワードと一致するか確認し、一致していれば「ＯＫ」、一致していなければ「ＮＧ」という結果を返す。生体認証の場合であれば、認証機能６２０は、本体アプリ６０のユーザ認証部６０１からユーザの生体情報（顔画像、声紋、虹彩、指紋、静脈など）を受け取り、その生体情報から抽出される特徴と本人情報６１０として登録されている本人特徴とを比較することにより本人か否かを判定し、本人と判定されたら「ＯＫ」、そうでなければ「ＮＧ」という結果を返す。ＰＩＮコード認証とパスワード認証と生体認証のうちの２つ以上を組み合わせたり、さらに他の認証方法を組み合わせることで、さらに高度なセキュリティを実現してもよい。
　暗号化機能６２１は、外部から与えられるデータに対し秘密鍵６１１を用いた暗号化を行う機能である。例えば、暗号化機能６２１は、本体アプリ６０のセキュリティ処理部６０２からデータを受け取り、そのデータを秘密鍵６１１を用いて暗号化し、暗号化されたデータ（暗号文）を返す。なお、暗号アルゴリズムはＲＳＡ、ＤＳＡ、ＥＣＤＳＡなどが好ましいが、それら以外のアルゴリズムを利用してもよい。
　電子署名機能６２２は、外部から与えられるデータに対し秘密鍵６１１を用いた電子署名を行う機能である。暗号化機能６２１との違いは、与えられたデータそのものを暗号化するのではなく、与えられたデータのハッシュ値を暗号化する点である。例えば、電子署名機能６２２は、本体アプリ６０のセキュリティ処理部６０２からデータを受け取り、ハッシュ関数６１４によりハッシュ値を計算し、ハッシュ値を秘密鍵６１１を用いて暗号化し、暗号化されたハッシュ値を返す。ハッシュ関数は何を用いてもよい（本実施形態では、ＳＨＡ－１とＳＨＡ－２５６を用いる）。なお、電子署名の対象となるデータのサイズが小さい場合には、ハッシュ値ではなく、データそのものを暗号化したものを電子署名として用いてもよい。
　本人情報変更機能６２３は、本人情報６１０をメモリ４１３に書き込んだり、メモリ４１３に格納されている本人情報６１０を更新又は削除する機能である。本体アプリ６０がＩＣカード３０７に対しユーザの情報を新規登録したり変更したりする場合には、この機能を利用する。
　鍵生成機能６２４は、秘密鍵６１１と公開鍵６１２の鍵ペアを生成する機能である。ＩＣカード３０７の初期状態においては、本人情報６１０、秘密鍵６１１、公開鍵６１２、電子証明書６１３などのユーザに紐付く情報はメモリ４１３内に格納されておらず、後述するＩＣカード発行手続のときにメモリ４１３に登録される（この操作をＩＣカードの活性化と呼ぶ）。このとき、秘密鍵６１１の生成とメモリ４１３への格納を、ＩＣカード３０７内の閉じられた空間の中で行う構成としたことで、秘密鍵６１１の漏えいリスクを低減することができる。なお、本実施形態では、メモリ４１３から秘密鍵６１１を読み出すＡＰＩを用意していないので、秘密鍵６１１が外部に漏えいするリスクはゼロに近い。
　公開鍵読出機能６２５はメモリ４１３から公開鍵６１２を読み出す機能である。また、電子証明書書込機能６２６はメモリ４１３に電子証明書６１３を書き込む機能であり、電子証明書読出機能６２７はメモリ４１３から電子証明書６１３を読み出す機能である。公開鍵６１２や電子証明書６１３は通信の相手先に配布するためのものなので、外部に読み出すことができるようになっている。なお、電子証明書６１３の書き込みは、ＩＣカード発行手続のときに必要となる。
　以上述べた構成によれば、ユーザ機器３０の本体アプリ６０は、ＩＣカード３０７を利用することにより公開鍵暗号によるデータの暗号化や電子署名を簡便に実現できる。また、ＩＣカード３０７の暗号化や電子署名の機能を利用するにはユーザ認証が必要であり、しかも秘密鍵の漏えいリスクはゼロに近いため、極めて堅牢なセキュリティが担保される。
　＜ＩＣカードの発行手続＞
　図７及び図８を参照して、ＩＣカード３０７の発行手続（ＩＣカードの活性化）を説明する。図７はＩＣカード発行端末を示す図であり、図８はＩＣカードの発行手続の流れを示す図である。
　ＩＣカード発行端末７０は、ＩＣカード３０７の新規発行を行う端末であり、例えば、携帯電話ショップ、サービス提供者の店頭（銀行など）、コンビニエンスストア、代理店窓口などに設置される。ＩＣカード発行端末７０は、ＩＣカードのリーダ／ライタを備えたコンピュータにより構成される。店員が操作するのであれば、汎用のパーソナルコンピュータやタブレット端末で構成してもよいし、ユーザ（ＩＣカードの申込者）本人に操作させるのであれば、キオスク端末にしてもよい。
　図８に沿って、発行手続の流れを説明する。ここで、「ユーザ」は、オンラインサービスを利用するためにＩＣカード３０７を新規に申し込む者である（図８の説明では、「ユーザ」又は「申込者」と称す）。「窓口」は、ＩＣカード発行端末７０を利用してＩＣカード３０７の発行業務を行う者である。「通信サービス管理者」は、ＩＣカード３０７の発行や運用の管理を担う者である。通信サービス管理者は、例えば、ＩＣカード３０７の提供、認証局への電子証明書の申請、発行済みＩＣカードの管理、ＩＣカード３０７とＳＩＭカード３０６の紐付け管理、ＩＣカード３０７の無効化（例えばユーザ機器３０の紛失・盗難・廃棄のとき）などの役割を担う。ＩＣカード３０７のセキュリティ機能は様々なオンラインサービスに利用できるため、通信サービス管理者はオンラインサービスのサービス提供者や中間サービス提供者とは異なる事業体で構成するとよい。「認証局」は公開鍵の電子証明書の発行及び失効を行う者である。
　ＩＣカードの申込者は、まず、窓口においてＩＣカードの利用申請を行う（ステップＳ８００）。利用申請にあたっては、申込者の本人確認情報を伝えると共に、本人確認書類（運転免許証など）を提出する。本人確認情報は、例えば、氏名、性別、生年月日、住所を含むとよい。また申込者は、ＩＣカードに登録するＰＩＮコードを指定する。窓口スタッフは、申込者から伝えられた情報を本人確認書類により照合することにより本人確認を行った後、それらの情報をＩＣカード発行端末７０に入力する（ステップＳ８０１）。なお、ＰＩＮコードが窓口スタッフに知得されないよう、ＰＩＮコードの入力だけは申込者本人に行わせてもよい。
　次に、窓口スタッフがＩＣカード発行端末７０に新規のＩＣカード３０７をセットし、活性化（アクティベート）処理の開始を指示する。この段階のＩＣカード３０７のメモリ４１３には、図６に示す情報のうち、「ハッシュ関数６１４、プログラム６１５」のみが格納されており、ユーザに紐付く情報である「秘密鍵６１１、公開鍵６１２、電子証明書６１３」は未だ格納されておらず、本人情報６１０のＰＩＮコードは初期値（例えば「００００」）である。まずＩＣカード発行端末７０は、認証機能６２０を利用して初期値のＰＩＮコードにより認証を行った後に、本人情報変更機能６２３を利用して申込者が指定したＰＩＮコードの登録を行うと共に、鍵生成機能６２４に鍵ペアの生成を指示して秘密鍵６１１と公開鍵６１２を生成させる（ステップＳ８０２）。ＰＩＮコードと鍵ペアはメモリ４１３の所定のエリア４１３１に書き込まれる。続いて、ＩＣカード発行端末７０は、公開鍵読出機能６２５を利用してメモリ４１３から公開鍵６１２を読み出し、この公開鍵６１２とステップＳ８０１で入力された本人確認情報とからＣＳＲ（Certificate Signing Request）を作成し、通信サービス管理者の管理サーバに送信する（ステップＳ８０３）。
　管理サーバは、ＩＣカード発行端末７０からＣＳＲを受信すると、そのＣＳＲを所定の認証局に対し送信する（ステップＳ８０４）。このとき、管理サーバは、本人確認情報に基づいて申込者の与信調査を実施してもよい。
　認証局は、受信したＣＳＲに従って申込者の公開鍵の電子証明書を発行し、管理サーバへ送付する（ステップＳ８０５）。電子証明書は公開鍵とその所有者を証明するものである。ＩＴＵ－Ｔにより策定されたＸ．５０９の場合、電子証明書は、公開鍵、所有者情報（本人確認情報が該当）、認証局の電子署名、電子証明書の有効期限、発行者の情報を含んだデータである。なお、認証局の電子署名は、電子証明書に含まれる公開鍵と所有者情報から生成したハッシュ値を認証局の秘密鍵で暗号化したものである。
　管理サーバは、発行された電子証明書をＩＣカード発行端末７０に送信する（ステップＳ８０６）。ＩＣカード発行端末７０は、ＩＣカード３０７の電子証明書書込機能６２６を利用して電子証明書をメモリ４１３に書き込む（ステップＳ８０７）。この段階で、ＩＣカード３０７のメモリ４１３には、セキュリティ処理に必要なデータである、本人情報６１０（本実施形態ではＰＩＮコード）、秘密鍵６１１、公開鍵６１２、電子証明書６１３が揃ったことになる。
　次に、ＩＣカード３０７を申込者のユーザ機器３０に装着する（ステップＳ８０８）。具体的には、ユーザ機器３０から通信用のＳＩＭカード３０６を取り出し、ＳＩＭカード３０６上にＩＣカード３０７を貼り付けた後、再びユーザ機器３０にＳＩＭカード３０６を挿入する。さらに、セットアッププログラムをユーザ機器３０にインストールし、セットアッププログラムによるＩＣカード３０７のセットアップ処理を実行する。ＩＣカード３０７の装着及びセットアップは、窓口スタッフが行ってもよいし、申込者自身が行ってもよい。
　セットアップ処理では、ユーザ機器３０（で動作するセットアッププログラム）が、ＩＣカード３０７から「シリアル番号」と「製造番号」を読み出すと共に、ＳＩＭカード３０６から「電話番号」と「製造番号」を読み出す。また、セットアッププログラムは、ユーザ機器３０自体の情報として「ＩＭＥＩ（International Mobile Equipment Identity）」を取得する。そしてセットアッププログラムは、それらの情報と共にＩＣカード登録要求を通信サービス管理者の管理サーバへ送信する（ステップＳ８０９）。管理サーバは、ユーザ機器３０からＩＣカード登録要求を受信すると、そこに含まれるＩＣカード３０７とＳＩＭカード３０６とユーザ機器３０の情報をＩＣカード管理データベースに登録する（ステップＳ８１０）。
　図９はＩＣカード管理データベースに格納されているＩＣカード管理情報のデータ構造の一例である。ＩＣカード３０７の「シリアル番号」及び「製造番号」に紐付けて、ＳＩＭカード３０６の「電話番号」及び「製造番号」とユーザ機器３０の「ＩＭＥＩ」が管理されている。図示しないが、ＩＣカード管理情報として、ユーザの本人確認情報（氏名、性別、住所、生年月日）、公開鍵、電子証明書の情報などを管理してもよい。
　ＩＣカード管理情報の登録が完了すると、管理サーバが、ユーザ機器３０に対して登録完了を通知する（ステップＳ８１１）。これによりユーザ機器３０のセットアップが完了し、ＩＣカード３０７が利用可能な状態（活性化状態）となる。
　なお、図８に示した発行手順はあくまで一例であり、異なる手順で発行手続を行っても構わない。例えば、秘密鍵、公開鍵、電子証明書、ＰＩＮコードが予め登録されたＩＣカード３０７を窓口に用意しておいてもよい。この場合は、ＩＣカード３０７への書き込み処理が不要なため、ＩＣカード発行端末７０を用いる必要がなくなり、ユーザ機器３０でのセットアップ処理だけで済み、ＩＣカードの発行手続が簡便となる。また、ＰＩＮコード認証ではなく、生体認証を用いる場合には、ＩＣカード３０７に本人情報として登録する生体情報（顔画像、声紋、虹彩、指紋など）をＩＣカード発行端末７０などを利用して入力すればよい。
　＜中間サービスへの初回登録＞
　図１０、図１１、及び図１２を参照して、中間サービスへの初回登録手続を説明する。図１０及び図１１は、中間サービスへの登録手続の流れを示す図であり、図１２は、ユーザ機器３０に表示される画面例である。なお、この段階では、オンラインサービスへのユーザ登録は既に済んでおり、オンラインサービス自体にログインするためのＩＤ・パスワードはユーザに付与されているものとする。
　まず、ユーザは、ユーザ機器３０を操作し、本体アプリ６０のダウンロード及びインストールを行う（ステップＳ１００１）。そして、ユーザは、本体アプリ６０を起動し、中間サービスのログイン画面を開く（ステップＳ１００２）。図１２に示すように、初回のログイン時には、ログイン画面１２０において中間サービスのユーザＩＤとパスワードを入力し、中間サービスにログインする（ステップＳ１００３）。このとき、本体アプリ６０は、中間サービスのユーザＩＤを不揮発性メモリに記憶する（ステップＳ１００４）。パスワードについては、セキュリティの観点からユーザ機器３０には記憶させないほうがよい。なお、ユーザＩＤとパスワードは、別途の手続である中間サービスの新規利用申込を行ったときに、中間サービス提供者から付与される情報である。
　ログインが完了すると、中間サーバ２１は、所定の電文（内容はどのようなものでもよい）をユーザ機器３０に送信し、電子署名と電子証明書を要求する（ステップＳ１００５）。
　本体アプリ６０のユーザ認証部６０１は、図１２に示すように、ＰＩＮコード入力画面１２１を表示する。ユーザによりＰＩＮコードが入力されると、ユーザ認証部６０１は、ＩＣカード３０７の認証機能６２０を利用して、入力されたＰＩＮコードが正しいか否かを確認する（ステップＳ１００６）。ＰＩＮコードが正しい場合（つまり、ユーザ認証に成功した場合）は、本体アプリ６０からＩＣカード３０７の他の機能６２１～６２７を利用可能となる。本体アプリ６０のセキュリティ処理部６０２は、ＩＣカード３０７の電子署名機能６２２を利用して、中間サーバ２１から受信した電文に電子署名を行うと共に、電子証明書読出機能６２７を利用して、メモリ４１３から電子証明書６１３を読み出す。そして、本体アプリ６０のメイン処理部６００は、電子署名付き電文と電子証明書６１３を中間サーバ２１に送信する（ステップＳ１００７）。
　中間サーバ２１は、ユーザ機器３０から受信した電子証明書６１３を用いて電子署名付き電文を検証する（ステップＳ１００８）。「検証」とは、電子証明書６１３に含まれる公開鍵によって電子署名付き電文を復号し、復号結果と元の電文との一致を調べることにより、電子署名がユーザ本人によって行われたこと（つまり、ユーザの秘密鍵によって電子署名が作成されたこと）を確認する操作である。なお、電子署名が電文そのものを暗号化したデータである場合は復号結果と元の電文とを比較すればよく、電子署名が電文のハッシュ値を暗号化したデータである場合は復号結果と元の電文のハッシュ値とを比較すればよい。
　検証に成功した場合、中間サーバ２１は、当該ユーザのユーザＩＤ・パスワードと電子証明書を紐付けて、ユーザ情報記憶部２１１に登録する（ステップＳ１００９）。そして、中間サーバ２１は、電子証明書の登録が完了した旨を本体アプリ６０へ通知する（ステップＳ１０１０）。中間サービスへの登録が完了すると、図１２に示すように、ユーザ機器３０にはメニュー画面１２２が表示される（ステップＳ１０１１）。
　続いて、ユーザと中間サービスとオンラインサービスの間の紐付けの手順を説明する。この紐付け処理は、ユーザが中間サービスを介してオンラインサービスの何らかの手続をはじめて利用したときや、ユーザが中間サービスのメニュー画面から銀行口座情報の登録を行ったときなどに実行される。図１０及び図１１では、ユーザが残高照会を行う例を示している。
　ユーザがメニュー画面１２２から「残高照会」を選択し、対象となる銀行口座の情報（銀行名、口座番号、口座名義など）を入力すると、本体アプリ６０が中間サーバ２１に対し残高照会要求を送信する（ステップＳ１０１２）。中間サーバ２１の代行制御部２１３は、照会先の銀行のサービス提供サーバ２０に対し残高照会要求を行う（ステップＳ１０１３）。この残高照会要求には、ユーザの銀行口座情報が含まれている。
　サービス提供サーバ２０のアクセス制御部２０２は、当該ユーザによる中間サーバ２１経由のアクセスが初回である場合には、ユーザに対しオンラインサービスのＩＤ・パスワードの入力を要請する（ステップＳ１０１４）。具体的には、図１２に示すように、ユーザ機器３０にオンラインサービスのログイン画面１２３が表示されるので（ステップＳ１０１５）、ユーザはオンラインサービスのユーザＩＤとパスワードを入力し、オンラインサービスにログインする（ステップＳ１０１６）。
　ログインが完了すると、サービス提供サーバ２０は、認証用電文（内容はどのようなものでもよい）をユーザ機器３０に送信し、電子署名と電子証明書を要求する（ステップＳ１０１７）。
　本体アプリ６０のユーザ認証部６０１は、図１２に示すように、ＰＩＮコード入力画面１２４を表示する。ユーザによりＰＩＮコードが入力されると、ユーザ認証部６０１は、ＩＣカード３０７の認証機能６２０を利用して、入力されたＰＩＮコードが正しいか否かを確認する（ステップＳ１０１８）。ＰＩＮコードが正しい場合（つまり、ユーザ認証に成功した場合）は、本体アプリ６０からＩＣカード３０７の他の機能６２１～６２７を利用可能となる。本体アプリ６０のセキュリティ処理部６０２は、ＩＣカード３０７の電子署名機能６２２を利用して、サービス提供サーバ２０から受信した認証用電文に電子署名を行うと共に、電子証明書読出機能６２７を利用して、メモリ４１３から電子証明書６１３を読み出す。そして、本体アプリ６０のメイン処理部６００は、電子署名付き認証用電文と電子証明書６１３をサービス提供サーバ２０に送信する（ステップＳ１０１９）。このとき、本体アプリ６０は、認証用電文を不揮発性メモリに記憶する（ステップＳ１０２０）。
　サービス提供サーバ２０は、ユーザ機器３０から受信した電子証明書６１３を用いて電子署名付き認証用電文を検証する（ステップＳ１０２１）。検証に成功した場合、サービス提供サーバ２０は、当該ユーザと中間サービスの組に対し、アクセストークンを発行する。本実施形態では、ＯＡｕｔｈ２．０の仕組みを利用して、中間サーバ２１によるオンラインサービスの代行を実現する。アクセストークンとは、中間サーバ２１がユーザに代わりオンラインサービスを利用する際の許可証のようなものである。ユーザ登録部２００は、認証用電文とアクセストークンと当該ユーザの電子証明書を紐付けて、ユーザ情報記憶部２０１に登録する（ステップＳ１０２３）。
　そして、サービス提供サーバ２０は、発行したアクセストークンと当該ユーザの口座残高の情報を中間サーバ２１へ通知する（ステップＳ１０２４）。中間サーバ２１は、受け取ったアクセストークンと当該ユーザの中間サービスのＩＤとを紐付けて、ユーザ情報記憶部２１１に登録する（ステップＳ１０２５）。なお、図示しないが、中間サーバ２１は、サービス提供サーバ２０から、アクセストークンと共にリフレッシュトークンも受け取る。リフレッシュトークンは、アクセストークンの再発行に利用されるトークンである。これはＯＡｕｔｈ２．０の仕様であるため、ここでは詳しい説明は割愛する。
　その後、中間サーバ２１は、口座残高の情報を本体アプリ６０へ通知する（ステップＳ１０２６）。図１２に示すように、ユーザ機器３０には口座残高の確認画面１２５が表示される（ステップＳ１０２７）。
　＜中間サービスへのログイン＞
　図１３及び図１４を参照して、中間サービスのログイン認証を説明する。図１３は、中間サービスのログイン認証の流れを示す図であり、図１４は、ユーザ機器３０に表示される画面例である。
　ユーザが、ユーザ機器３０において本体アプリ６０を起動すると、ユーザ認証部６０１が、図１４に示すように、ＰＩＮコード入力画面１４０を表示する（ステップＳ１３００）。ユーザによりＰＩＮコードが入力されると、ユーザ認証部６０１は、ＩＣカード３０７の認証機能６２０を利用して、入力されたＰＩＮコードが正しいか否かを確認する（ステップＳ１３０１）。ＰＩＮコードが正しい場合（つまり、ユーザ認証に成功した場合）、本体アプリ６０のセキュリティ処理部６０２は、ＩＣカード３０７の電子署名機能６２２を利用して、中間サービスのユーザＩＤと認証用電文に対し電子署名を行う（ステップＳ１３０２）。そして、本体アプリ６０のメイン処理部６００は、ログイン要求を中間サーバ２１に送信する（ステップＳ１３０３）。ログイン要求には、中間サービスのユーザＩＤ、認証用電文、電子署名が付加されている。
　中間サーバ２１のログイン制御部２１２は、ログイン要求を受信すると、ログイン要求に含まれるユーザＩＤに基づいて、ユーザ情報記憶部２１１から対応する電子証明書を読み出し、この電子証明書を用いて、ログイン要求に含まれている電子署名の検証を行う（ステップＳ１３０４）。また、必要に応じて、ログイン制御部２１２は、電子証明書の有効性を認証局に問い合わせてもよい（ステップＳ１３０５、Ｓ１３０６）。電子署名の検証に成功し、且つ、電子証明書の有効性が確認された場合、ログイン制御部２１２は、ログイン要求が正当なユーザからのものであると判断する。
　続いて、中間サーバ２１のログイン制御部２１２は、ログイン要求に含まれるユーザＩＤに基づいて、ユーザ情報記憶部２１１からオンラインサービスのアクセストークンを読み出し、サービス提供サーバ２０にアクセス要求を送信する（ステップＳ１３０７）。このアクセス要求には、アクセストークンと、ログイン要求に含まれていた認証用電文及び電子署名とが付加されている。
　サービス提供サーバ２０のアクセス制御部２０２は、アクセス要求を受信すると、アクセス要求に含まれるアクセストークンに基づいて、ユーザ情報記憶部２０１から対応する電子証明書を読み出し、この電子証明書を用いて、アクセス要求に含まれている電子署名の検証を行う（ステップＳ１３０８）。また、必要に応じて、アクセス制御部２０２は、電子証明書の有効性を認証局に問い合わせてもよい（ステップＳ１３０９、Ｓ１３１０）。電子署名の検証に成功し、且つ、電子証明書の有効性が確認された場合、アクセス制御部２０２は、アクセス要求が、ユーザから代行権限が与えられた中間サーバ２１からのものであると判断し、中間サーバ２１に対しアクセス許可を与える（ステップＳ１３１１）。
　オンラインサービスのアクセス許可が得られたら、中間サーバ２１は、ログイン認証ＯＫを本体アプリ６０に通知する（ステップＳ１３１２）。以後、図１４に示すように、ユーザ機器３０に中間サービスのメニュー画面１４１が表示され、ユーザは希望する手続を行うことができようになる。
　以上述べたログイン認証によれば、ユーザはＰＩＮコードを入力するだけでよいので、従来のＩＤ・パスワードを都度入力する方法や、トークンを用いる方法に比べて、非常に簡便な操作でログインが可能となる。しかも、ＩＣカード３０７により提供されるセキュリティ機能を利用しているため、高度のセキュリティも担保されている。
　また、本実施形態の方法は、オンラインサービスのＩＤ・パスワードの情報を中間サービス側に一切提供することなく、中間サービスとオンラインサービスとの紐付けが可能となる。したがって、オンラインバンキングのＩＤ・パスワードを別の事業者に開示することに抵抗を感じる利用者でも、安心してこのサービスを利用することができる。
　＜オンラインサービスの利用＞
　図１５及び図１６を参照して、中間サービス利用時の手順を説明する。図１５は、中間サービス利用時の流れを示す図であり、図１６は、ユーザ機器３０に表示される画面例である。中間サービスへのログインは既に完了しており、ユーザ機器３０にはメニュー画面１６０が表示されているものとする。
　ユーザがメニュー画面１６０から利用したい手続を選択すると、詳細画面１６１に遷移する（ステップＳ１５００）。図１６では、ユーザが「振込」を選択した場合の画面例が示されている。この詳細画面１６１においてユーザが必要な情報（例えば振込先、振込額など）を入力し、実行ボタンを押すと（ステップＳ１５０１）、本体アプリ６０のメイン処理部６００が、振込手続に必要な情報を記述した手続メッセージを作成する（ステップＳ１５０２）。
　続いて、本体アプリ６０のユーザ認証部６０１が、ＰＩＮコード入力画面１６２を表示し、ＰＩＮコード認証を行う（ステップＳ１５０３）。ＰＩＮコード認証の手順は前述したものと同様のため、説明を省略する。ＰＩＮコード認証に成功した場合、本体アプリ６０のセキュリティ処理部６０２は、ＩＣカード３０７の電子署名機能６２２を利用して、手続メッセージに対し電子署名を行う（ステップＳ１５０４）。このとき、電子署名機能６２２は、手続メッセージのハッシュ値を計算し、このハッシュ値を秘密鍵６１１で暗号化することにより電子署名を生成してもよいし、手続メッセージ自体を秘密鍵６１１で暗号化することにより電子署名を生成してもよい。そして、本体アプリ６０のメイン処理部６００は、手続要求を中間サーバ２１に送信する（ステップＳ１５０５）。手続要求には、中間サービスのＩＤ、手続メッセージ、電子署名が付加されている。
　中間サーバ２１の代行制御部２１３は、手続要求を受信すると、手続要求に含まれるユーザＩＤに基づいて、ユーザ情報記憶部２１１から対応する電子証明書を読み出し、この電子証明書を用いて、手続要求に含まれている電子署名の検証を行う（ステップＳ１５０６）。また、必要に応じて、代行制御部２１３は、電子証明書の有効性を認証局に問い合わせてもよい（ステップＳ１５０７、Ｓ１５０８）。電子署名の検証に成功し、且つ、電子証明書の有効性が確認された場合、代行制御部２１３は、手続要求が正当なユーザからのものであると判断する。すなわち、第三者によるなりすましがなく、かつ、手続メッセージの内容も改ざんされていないと判断するのである。
　手続要求が正当なユーザからのものであると確認できた場合、代行制御部２１３は、手続要求に含まれるユーザＩＤ及び手続メッセージに基づいて、ユーザ情報記憶部２１１から対応するオンラインサービスのアクセストークンを読み出し、サービス提供サーバ２０に手続要求を送信する（ステップＳ１５０９）。この手続要求には、アクセストークンと、ユーザ機器３０から受信した手続メッセージ及び電子署名とが付加されている。
　サービス提供サーバ２０の手続制御部２０３は、手続要求を受信すると、手続要求に含まれるアクセストークンに基づいて、ユーザ情報記憶部２０１から対応する電子証明書を読み出し、この電子証明書を用いて、手続要求に含まれている電子署名の検証を行う（ステップＳ１５１０）。また、必要に応じて、手続制御部２０３は、電子証明書の有効性を認証局に問い合わせてもよい（ステップＳ１５１１、Ｓ１５１２）。電子署名の検証に成功し、且つ、電子証明書の有効性が確認された場合、手続制御部２０３は、この手続要求が正当なユーザからのものであると判断する。すなわち、第三者によるなりすましがなく、かつ、手続メッセージの内容も改ざんされていないと判断するのである。
　手続要求が正当なユーザからのものであると確認できた場合にのみ、手続制御部２０３は、手続メッセージに記述された情報に基づく手続（振込など）を実行する（ステップＳ１５１３）。手続が完了すると、手続制御部２０３は手続完了通知を中間サーバ２１に送信し（ステップＳ１５１４）、中間サーバ２１が手続完了通知を本体アプリ６０に送信する（ステップＳ１５１５）。そうすると、図１６に示すように、手続完了画面１６３が表示される。
　以上述べた処理によれば、ユーザはＰＩＮコードを入力するだけでよいので、従来のＩＤ・パスワードを都度入力する方法や、トークンを用いる方法に比べて、非常に簡便な操作で中間サービス及びオンラインサービスの利用が可能となる。しかも、ＩＣカード３０７により提供されるセキュリティ機能を利用しているため、高度のセキュリティも担保され、いわゆる中間者攻撃によるなりすましや手続メッセージの改ざんを防止することが可能となる。
　なお、図１５の例では、ユーザ機器３０から送られる手続要求に平文の手続メッセージが含まれている。これは、中間サーバ２１（中間サービス提供者）でも手続メッセージの改ざんが行われていないかを検証できるようにするためである。しかしながら、場合によっては、手続メッセージの中に、サービス提供者以外の者に知られたくない情報もしくは伝える必要の無い情報が含まれていることも想定される。例えば、オンラインで住所変更手続を行う際には、その手続メッセージの中に変更後の住所情報が含まれることとなるが、住所のような個人情報はプライバシーに関わるため、中間サービス提供者に知られたくないと希望するユーザは少なくない。また、銀行は住所情報を管理する法的義務があるが、中間サービス提供者にはその義務はないため、中間サービス提供者の側も、必要のない個人情報は受け取りを避けたいと考えるかもしれない。
　そこで、ユーザ機器３０がサービス提供サーバ２０（サービス提供者）の公開鍵を用いて手続メッセージを暗号化してもよい。すなわち、ユーザ機器３０の本体アプリ６０が、住所変更手続などの手続メッセージをサービス提供サーバ２０の公開鍵により暗号化した後、暗号化された手続メッセージに対しユーザの秘密鍵６１１による電子署名を行い、ＩＤ・暗号化された手続メッセージ・電子署名を含む手続要求を中間サーバ２１に送信するのである。
　この方法によれば、中間サーバ２１は、電子署名を検証することによって、手続要求が正当なユーザから送られてきたものであることは確認できるが、手続メッセージの内容を確認することはできない。一方、サービス提供サーバ２０は、自身が保管する秘密鍵を用いて手続メッセージを復号することにより、手続メッセージの内容（ユーザの住所情報など）を確認でき、手続を遂行することができる。したがって、中間サービス提供者による中間サービスを経由しつつも、中間サービス提供者には秘匿した状態で、サービス提供者にのみ情報を伝達する、という仕組みが実現できる。
　＜ＩＣカードの無効化＞
　本実施形態のユーザ機器３０によれば、ＰＩＮコードや生体情報によるユーザ認証に成功しなければ、中間サービス及びオンラインサービスを利用することができない。したがって、仮にユーザ機器３０の紛失や盗難が起きた場合でも、第三者によるユーザ機器３０の不正使用のリスクは小さい。とはいえ、ＰＩＮコード認証や生体認証が破られる可能性はゼロではないことから、好ましくは、以下に述べるようなＩＣカードの無効化機能を実装するとよい。
　（１）ＩＣカードの自滅機能
　自滅とは、ＩＣカード３０７のプロセッサ４１１自身がＩＣカード３０７の機能を無効化する操作である。具体的な操作としては、外部（本体アプリ６０）からＩＣカード３０７の機能を利用できないようにロックをかけたり、メモリ４１３に格納されているデータ（鍵ペア、電子証明書など）を消去したりする方法などがある。例えば、誤ったＰＩＮコードが連続して所定回数入力された場合、ＡＰＩ以外の方法でメモリ４１３へのアクセスが行われた場合などに、プロセッサ４１１は自滅を実行するとよい。
　（２）ＩＣカードの無効化
　通信サービス管理者が、ユーザから、ユーザ機器３０又はＩＣカード３０７の紛失・盗難の報告を受けた場合に、管理サーバからユーザ機器３０又はＩＣカード３０７に対して無効化信号を送信し、ＩＣカード３０７を無効化してもよい。あるいは、管理サーバが、ＩＣカード３０７の使用状況を監視し、異常を検知した場合（例えば、不使用状態が長期間続いた場合、使用頻度が突然増加した場合、大金を送金しようとした場合など）にＩＣカード３０７を無効化してもよい。あるいは、管理サーバが、ＩＣカード３０７とＳＩＭカード３０６とユーザ機器３０の組み合わせを監視し、ＩＣカード管理情報で管理されている情報との齟齬を検知した場合（例えば、ＩＣカードが単独又はＳＩＭカードと一緒に抜き取られ、他の携帯機器に装着された場合などに、そのような齟齬が発生し得る）にＩＣカード３０７を無効化してもよい。無効化の方法も、外部（本体アプリ６０）からＩＣカード３０７の機能を利用できないようにロックをかけたり、メモリ４１３に格納されているデータ（鍵ペア、電子証明書など）を消去したりする方法などがある。
　（３）電子証明書の無効化
　通信サービス管理者が、ユーザから、ユーザ機器３０又はＩＣカード３０７の紛失・盗難の報告を受けた場合に、管理サーバから認証局に対して当該ユーザの電子証明書の無効化を依頼してもよい。あるいは、管理サーバが、ＩＣカード３０７の使用状況やＩＣカード・ＳＩＭカード・ユーザ機器の組み合わせを監視し、異常を検知した場合に認証局に電子証明書の無効化を依頼してもよい。
　＜その他＞
　上述した実施形態は本発明の具体例の一つを説明したにすぎず、本発明の技術的範囲は上述した実施形態の内容に限定されるものではなく、また本発明はその技術思想の範囲内で様々な具体的形態を採り得るものである。例えば、本発明はオンラインバンキングサービス以外にも様々な種類のオンラインサービスに適用することができる。また、上述した実施形態ではサブＳＩＭタイプのＩＣカードを例示したが、ＳＩＭカードスロットを複数備える携帯機器であれば、一般的なｍｉｃｒｏ－ＳＩＭやｎａｎｏ－ＳＩＭと同じ仕様のＩＣカードを（通信用ＳＩＭカードとは別のスロットに）装着してもよい。あるいは、ＳＩＭカードスロット以外のスロットに装着するタイプのＩＣカードを用いてもよいし、携帯機器に内蔵されたＩＣチップ（例えばSecure Elementなど）を用いてもよい。また、上述した実施形態では、ログイン要求の中に電子署名付きユーザＩＤのみ含めたが、さらに電子証明書を一緒に送ってもよい。また、上述した実施形態では、ユーザ機器から中間サーバに送るデータにのみ電子署名を行ったが、中間サーバやサービス提供サーバがユーザ機器に送るデータに対し電子署名や暗号化を行うことも好ましい。その場合、中間サーバやサービス提供サーバは、自身の暗号鍵で電子署名や暗号化を行ってもよいし、ユーザの公開鍵で暗号化を行ってもよい。
　＜セキュアエレメント＞
　上述した実施形態では、サブＳＩＭタイプのＩＣカードによって暗号化機能（セキュリティ機能）を提供したが、暗号化機能の全部又は一部を、ユーザ機器３０に内蔵もしくは接続されたセキュアエレメント１６００によって提供してもよい。図１７は、セキュアエレメント１６００を内蔵するユーザ機器３０のハードウェア構成を模式的に示すブロック図である。
　セキュアエレメント１６００とは格納したデータを外部から解析されることへの耐性（耐タンパー性）を持ち、主に機密情報を管理するために用いられるＩＣチップである。セキュアエレメント１６００は、ユーザ機器３０本体の制御基板３０９（プロセッサ１６１１、ＲＡＭ１６１２、不揮発性メモリ１６１３を有する）とは独立したＩＣチップであり、プロセッサ１６０１、ＲＡＭ１６０２、不揮発性メモリ１６０３を有している。セキュアエレメント１６００はユーザ機器３０本体のプロセッサ１６１１などと通信を行う。
　暗号化機能をセキュアエレメント１６００により提供する場合、暗号化機能で用いるデータ（図６に示す、本人情報６１０、秘密鍵６１１、公開鍵６１２、電子証明書６１３、ハッシュ関数６１４、プログラム６１５など）はセキュアエレメント１６００内の不揮発性メモリ１６０３に格納されるとよい。また、暗号化機能（図６に示す、認証機能６２０、暗号化機能６２１、電子署名機能６２２、本人情報変更機能６２３、鍵生成機能６２４、公開鍵読出機能６２５、電子証明書書込機能６２６、電子証明書読出機能６２７など）はセキュアエレメント１６００のプロセッサ１６０１がプログラム６１５を実行することにより提供されるとよい。
　以上述べた構成によれば、ユーザ機器以外のデバイス（従来のトークンのようなもの）を持ち歩く必要がなく、ユーザ機器単体でオンラインサービスの利用が可能となるため、利便性が高い。また、アプリの起動と本人認証だけで自動ログインが可能なため、スマートかつ簡便な操作性を実現できる。さらに、セキュアエレメント１６００に格納された秘密鍵と、セキュアエレメント１６００が提供する暗号化機能を利用するため、セキュアなデータ通信を実現できる。この秘密鍵は漏えいのリスクが小さく、また、ＰＩＮコードやパスワードや生体認証による本人認証をクリアしなければ秘密鍵や暗号化機能を利用することもできないので、第三者による不正利用のリスクを可及的に小さくできる。
　＜ＳＩＭカード＞
　暗号化機能の全部又は一部が、ユーザ機器３０に内蔵もしくは接続されたＳＩＭカードによって提供されてもよい。図１８は、ＳＩＭカード１７００を備えるユーザ機器３０のハードウェア構成を模式的に示すブロック図である。
　ＳＩＭカード１７００は、プロセッサ１７０１、ＲＡＭ１７０２、不揮発性メモリ１７０３、及び、８つのピン１７０５（電極）を有する。不揮発性メモリ１７０３には、ＳＩＭカード１７００のユニークなシリアルナンバー（ＩＣＣＩＤ）、加入者識別情報（ＩＭＳＩ）などのデータと、暗号化機能で利用するデータと、プロセッサ１７０１で実行されるプログラムとが格納されている。８つのピン１７０５は、電源入力端子、リセット端子、クロック端子、アース端子、プログラム用電圧入力端子、Ｉ／Ｏ端子、予備端子を含む。
　図１８は、ＳＩＭカード１７００がＳＩＭカードスロット１７０４に装着された状態を模式的に示している。ＳＩＭカード１７００のピン１７０５がユーザ機器３０の制御基板３０９の端子１７０６に接続される。
　ＳＩＭカード１７００は、ユーザが移動体通信事業者（ＭＮＯ）又は仮想移動体通信事業者（ＭＶＮＯ）の提供する移動通信サービスに加入したときに、その事業者から提供されるものである。ＳＩＭカード１７００に格納されるデータやプログラムは事業者ごとに相違しているが、ＳＩＭカード１７００自体の基本的な構造は国際規格に準拠している限りにおいて同一である。ＳＩＭカード１７００としては、標準－ＳＩＭ、ｍｉｃｒｏ－ＳＩＭ、ｎａｎｏ－ＳＩＭのいずれのタイプを用いてもよい。
　暗号化機能をＳＩＭカード１７００により提供する場合、暗号化機能で用いるデータ（図６に示す、本人情報６１０、秘密鍵６１１、公開鍵６１２、電子証明書６１３、ハッシュ関数６１４、プログラム６１５など）はＳＩＭカード１７００内の不揮発性メモリ１７０３に格納されるとよい。また、暗号化機能（図６に示す、認証機能６２０、暗号化機能６２１、電子署名機能６２２、本人情報変更機能６２３、鍵生成機能６２４、公開鍵読出機能６２５、電子証明書書込機能６２６、電子証明書読出機能６２７など）はＳＩＭカード１７００のプロセッサ１６０１がプログラム６１５を実行することにより提供されるとよい。
　以上述べた構成によれば、ユーザ機器以外のデバイス（従来のトークンのようなもの）を持ち歩く必要がなく、ユーザ機器単体でオンラインサービスの利用が可能となるため、利便性が高い。また、アプリの起動と本人認証だけで自動ログインが可能なため、スマートかつ簡便な操作性を実現できる。さらに、ＳＩＭカード１７００に格納された秘密鍵と、ＳＩＭカード１７００が提供する暗号化機能を利用するため、セキュアなデータ通信を実現できる。この秘密鍵は漏えいのリスクが小さく、また、ＰＩＮコードやパスワードや生体認証による本人認証をクリアしなければ秘密鍵や暗号化機能を利用することもできないので、第三者による不正利用のリスクを可及的に小さくできる。
　＜電子証明書のポストインストール＞
　図１９を用いて、電子証明書のポストインストールについて説明する。図８に示した手順では、窓口において電子証明書がインストールされたＩＣカードをユーザに引き渡したのに対し、図１９に示す手順（ポストインストール）では、ユーザ機器に内蔵又は接続されたＩＣカードやＩＣチップに後から電子証明書を書き込むことができる点が異なる。
　ＩＣカードの申込者（ユーザ）は、まず、窓口においてＩＣカードの利用申請を行う（ステップＳ１８００）。利用申請にあたっては、ユーザの本人確認情報及び電話番号を手続端末に入力すると共に、本人確認書類（運転免許証、住民票など）を提出する。本人確認情報は、例えば、氏名、性別、生年月日、住所を含むとよい。電話番号は、ユーザ機器３０に装着された通信用のＳＩＭカードに割り当てられた電話番号である。ユーザは、これらの本人確認情報及び電話番号を手続端末に入力する（ステップＳ１８０１）。本人確認書類については、手続端末に備えられたカメラ又はスキャナによって電子データ化（例えば画像データ）されるとよい。手続端末は本人確認情報と本人確認書類と電話番号を通信サービス管理者に送信する（ステップＳ１８０２）。なお、ここではユーザが自ら手続端末を操作し、必要な情報を入力する手順を想定するが、図８の場合と同じように窓口スタッフが入力を代行してもよい。
　一方、ユーザは、暗号化機能をインストール及びアクティベートするための所定のプログラム（「セットアッププログラム」と呼ぶ）をユーザ機器３０にインストールする（図６に示す本体アプリ６０がセットアッププログラムを兼ねていてもよい）。そして、ユーザ機器３０のプロセッサは、セットアッププログラムによって、通信用のＳＩＭカードから電話番号とＩＭＳＩを読み込み（ステップＳ１８０３）、ＳＩＭカードの電話番号とＩＭＳＩを通信サービス管理者に送信する（ステップＳ１８０４）。
　この後、ユーザは、ＩＣカードを受け取り、ユーザ機器３０に装着する。この段階のＩＣカードのメモリには、図６に示す情報のうち、「ハッシュ関数、プログラム」のみが格納されており、ユーザに紐付く情報である「秘密鍵、公開鍵、電子証明書」は未だ格納されていない。
　通信サービス管理者は、電話番号をキーとして、ユーザ機器３０から受信した情報と手続端末から受信した情報の対応をとり、本人確認情報と本人確認書類とＳＩＭカードの電話番号及びＩＭＳＩとを紐づけて記憶する。そして、通信サービス管理者は、本人確認情報を本人確認書類と照合し、情報に齟齬がないかをチェックすることにより本人確認を行う（ステップＳ１８０６）。本人確認完了後、通信サービス管理者は、証明書発行依頼とユーザ機器３０から受信した通信用ＳＩＭカードの電話番号及び／又はＩＭＳＩを認証局に送信する（ステップＳ１８０７）。なお、本例では電話番号及び／又はＩＭＳＩをユーザ機器３０が通信サービス管理者を介して間接的に認証局に通知したが、電話番号及び／又はＩＭＳＩをユーザ機器３０が直接的に認証局に通知してもよい。また、本例では本人確認書類の電子データを通信サービス管理者にネットワークを介して送信したが、本人確認書類の原本確認が必要な場合は、窓口又はユーザから通信サービス管理者に本人確認書類の原本を提出ないし郵送するようにしてもよい。この場合は、通信サービス管理者が本人確認書類の原本を受領したのち、ステップＳ１８０６の本人確認処理が開始される。
　証明書発行依頼を受信した認証局は、利用者識別符号を生成し、ＩＭＳＩ又は電話番号により特定される送信先に利用者識別符号を送信する（ステップＳ１８０８）。利用者識別符号の送信手段としては、例えば、ＳＭＳ（ショートメッセージサービス）を利用することができる。ユーザ機器３０のセットアッププログラムは、ＩＣカードの鍵生成機能６２４に鍵ペアの生成を指示して秘密鍵と公開鍵を生成させる（ステップＳ１８０９）。なお、利用者識別符号の送付（ステップＳ１８０８）と鍵ペア生成（ステップＳ１８０９）の順序は問わない。
　その後、ユーザ機器３０のセットアッププログラムは、ＩＣカードの公開鍵読出機能６２５を利用して、ＩＣカードのメモリから公開鍵を読み出し、この公開鍵と利用者識別符号とから電子証明書の発行要求であるＣＳＲ（Certificate Signing Request）を作成し、所定の認証局に送信する（ステップＳ１８１０）。
　認証局は、受信したＣＳＲに従ってユーザの公開鍵の電子証明書を発行し、ユーザ機器３０へ、有線インターネット経由あるいは無線インターネット経由で送信する（ステップＳ１８１１）。このとき、プロトコルとしてＨＴＴＰ（Hypertext Transfer Protocol）又はＨＴＴＰＳ（Hypertext Transfer Protocol Secure）を用いて送信してもよい。電子証明書を認証局から受信する処理も、ユーザ機器３０のセットアッププログラムによって行われる。
　電子証明書は電子的に利用者が本人であることを証明するものである。本実施形態では、電子証明書として、公開鍵とその所有者の同定情報を結びつける公開鍵証明書が用いられる。ＩＴＵ－Ｔにより策定されたＸ．５０９の場合、電子証明書は、公開鍵、所有者情報（本人確認情報が該当）、認証局の電子署名、電子証明書の有効期限、発行者の情報を含んだデータである。なお、認証局の電子署名は、電子証明書に含まれる公開鍵と所有者情報から生成したハッシュ値を認証局の秘密鍵で暗号化したものである。
　認証局が電子証明書をユーザ機器３０へ送信するタイミング、あるいは、ユーザ機器３０が電子証明書を認証局から受信するタイミングは、任意に制御できる。例えば、ユーザ機器３０のセットアッププログラムがバックグラウンドで定期的に認証局と通信を行い、電子証明書の発行が完了したか否かを確認し、準備が整った段階で電子証明書をダウンロードしてもよい。あるいは、認証局がＣＳＲを受信したときに、ユーザ機器３０に対し、電子証明書の発行予定日時（ダウンロードが可能となる日時）を通知してもよい。その場合、ユーザ機器３０のセットアッププログラムは、通知された発行予定日時の経過後に、認証局にアクセスし電子証明書を取得すればよい。あるいは、ＳＭＳやプッシュ通知などの仕組みを用いて、認証局が、電子証明書の発行が完了した旨をユーザ機器３０のセットアッププログラムに通知し、応答したセットアッププログラムに対し電子証明書を送信してもよい。このように、電子証明書の発行依頼と電子証明書のユーザ機器への送信とを異なるタイミングで行えるようにしたことにより、例えば、本人確認までの業務を店頭窓口で行い、電子証明書発行以降のフローはユーザが希望する時間帯に行うというように、時間や場所の制限のないオペレーションが可能となる。したがって、暗号化機能のインストール及びアクティベーションの利便性向上を図ることができる。なお、いずれの方法の場合でも、ユーザ機器３０のセットアッププログラムは、利用者識別符号とともに通信用ＳＩＭカードの電話番号及び／又はＩＭＳＩを認証局に通知することによって、申込者本人の端末（正当な端末）であることを認証局に証明するとよい。これにより、電子証明書の発行依頼とユーザ機器への送信とが異なるタイミングで行われる場合においても、別人の端末に誤って電子証明書を送信するといったミスの発生を防ぐことができる。また、悪意をもった者が不正に電子証明書を取得することも抑制できるため、電子証明書の発行及び送信を安全に行うことができる。
　ユーザ機器３０のセットアッププログラムは、ＩＣカードの電子証明書書込機能６２６を利用して電子証明書をＩＣカードのメモリに書き込む（ステップＳ１８１２）。この段階で、ＩＣカードのメモリには、セキュリティ処理に必要なデータである、本人情報、秘密鍵、公開鍵、電子証明書が揃ったことになる。このとき、電子証明書をユーザ機器３０に搭載されるＳＩＭカードやセキュアエレメントに格納してもよい。
　ユーザ機器３０のセットアッププログラムは、ＩＣカードから「シリアル番号」と「製造番号」を読み出すと共に、通信用のＳＩＭカードから「電話番号」と「ＩＭＳＩ」を読み出す。また、セットアッププログラムは、ユーザ機器自体の情報として「ＩＭＥＩ（International Mobile Equipment Identity）」を取得する。そしてセットアッププログラムは、それらの情報と共にＩＣカード登録要求を通信サービス管理者の管理サーバへ送信する。管理サーバは、ユーザ機器３０からＩＣカード登録要求を受信すると、そこに含まれるＩＣカードとＳＩＭカードとユーザ機器の情報をＩＣカード管理データベースに登録する（ステップＳ１８１４）。
　ＩＣカード管理情報の登録が完了すると、管理サーバが、ユーザ機器３０に対して登録完了を通知する。これによりユーザ機器３０のセットアップが完了し、ＩＣカードが利用可能な状態（活性化状態）となる。
　なお、図１９に示した発行手順はあくまで一例であり、異なる手順で発行手続を行っても構わない。例えば、ＳＭＳの代わりにインターネットを介したデータ通信により利用者識別符号をユーザ機器に送信してもよい。このとき、通信用のＳＩＭカードのＩＭＳIを用いてユーザ機器のＩＰアドレスを特定してもよい。また、ＰＩＮコード認証ではなく、生体認証を用いる場合には、ＩＣカードに本人情報として登録する生体情報（顔画像、声紋、虹彩、指紋など）を手続端末などを利用して入力してもよい。
　＜ＩＣチップの特定＞
　図２０は、ユーザ機器と中間サーバとの間で通信を行う際に、ユーザ機器において利用されるＩＣチップを特定するための仕組みの一例を示す図である。図２０の例では、ユーザ機器３０が２つのＩＣチップ１９０、１９１を有しており、ＩＣチップ１９０がサーバＡ１９２との通信に利用され、ＩＣチップ１９１がサーバＢ１９３との通信に利用されるものとする。ＩＣチップ１９０、１９１としては、前述したサブＳＩＭタイプのＩＣカード、通信用のＳＩＭカード、セキュアエレメントなどのほか、いかなるタイプのＩＣチップを利用してもよい。
　各ＩＣチップ１９０、１９１には、ユニークなＩＤが割り振られている。このＩＤは、ＩＣチップを一意に特定しうる識別情報であって、ＩＣチップの内蔵メモリ内に格納されている。図２０の例では、ＩＣチップ１９０のＩＤは「ａａａ１」であり、ＩＣチップ１９１のＩＤは「ｂｂｂ２」である。ＩＤとしては、他のＩＣチップと重ならなければいかなる情報でもよい。例えば、ＩＭＳＩ（International Mobile Subscriber Identity）、ＩＣＣＩＤ（Integrated Circuit Card ID）、電話番号、シリアル番号、製造番号などをＩＤとして用いることができる。また、ＩＭＳＩなどに対応づけられたＩＰアドレスをＩＤとして用いてもよい。
　ユーザ機器３０の本体アプリ６０は、サーバＡ１９２に送信するデータ（通信パケット）１９４のヘッダなどに、送信元の情報として、ＩＣチップ１９０のＩＤ「ａａａ１」を付加する。これにより、サーバＡ１９２は、ユーザ機器３０において使用されているＩＣチップ１９０を特定することができる。またサーバＡ１９２も、ユーザ機器３０に送信するデータ（通信パケット）１９４のヘッダなどに、送信先の情報として、ＩＣチップ１９０のＩＤ「ａａａ１」を付加する。このＩＤにより、本体アプリ６０は、サーバＡ１９２から受信したデータの処理を担当するＩＣチップ１９０を特定することができる。
　一方、ユーザ機器３０の本体アプリ６０は、サーバＢ１９３に送信するデータ（通信パケット）１９５のヘッダなどに、送信元の情報として、ＩＣチップ１９１のＩＤ「ｂｂｂ２」を付加する。これにより、サーバＢ１９３は、ユーザ機器３０において使用されているＩＣチップ１９１を特定することができる。またサーバＢ１９３も、ユーザ機器３０に送信するデータ（通信パケット）１９５のヘッダなどに、送信先の情報として、ＩＣチップ１９１のＩＤ「ｂｂｂ２」を付加する。このＩＤにより、本体アプリ６０は、サーバＡ１９２から受信したデータの処理を担当するＩＣチップ１９０を特定することができる。
　以上述べた構成によれば、ユーザ機器３０と各サーバとの間において、送信元又は送信先となるＩＣチップを特定したデータ送受信が行われるため、通信の安全性をより高めることができる。また、図２０に示すように、ＩＣチップとサーバの組み合わせが複数組ある場合には、本体アプリ６０がデータ１９４、１９５のヘッダに含まれるＩＤ情報に基づいて、データ１９４、１９５の処理に利用すべきＩＣチップ１９０、１９１を選択（切り替え）することができる。このような利点は、ユーザ機器３０が複数のＩＣチップを備えている場合や、ユーザ機器３０が複数のサーバとセキュアな通信を行う場合などに、特にメリットが大きい。
　図２０の例では、ユーザ機器３０と各サーバとの間で送受信されるデータにＩＣチップの識別情報を付加することによって、ＩＣチップとサーバとの対応付けを行ったが、別の方法で同様のことを実現しても構わない。例えば、図２１に示すように、本体アプリ６０が、ＩＣチップとサーバとの対応付けを行う対応付け情報１９６（以下、「対応テーブル１９６」と呼ぶ）を有していてもよい。対応テーブル１９６では、例えば、ＩＣチップの識別情報と、そのＩＣチップの暗号化機能を利用して通信を行うサーバの識別情報との対応付けが行われるとよい。ＩＣチップの識別情報としては、例えば、ＩＭＳＩ（International Mobile Subscriber Identity）、ＩＣＣＩＤ（Integrated Circuit Card ID）、電話番号、シリアル番号、製造番号、ＩＭＳＩに対応付けられたＩＰアドレスなどを用いてもよい。また、サーバの識別情報としては、例えば、サーバのＩＰアドレス、ＵＲＬなどを用いてもよい。図２１に示す方法の場合、本体アプリ６０が、サーバと通信を行う際に、対応テーブル１９６に基づいて、サーバとの通信において利用するＩＣチップを特定することができる。したがって、図２０の方法と同様の効果を奏することが可能である。
　＜サーバ間の通信のセキュリティ＞
　上述した実施形態では、ユーザ機器３０と中間サーバ２１とサービス提供サーバ２０の３者間の通信を、ＩＣチップを利用した公開鍵暗号方式によって保護している。この方式は高度なセキュリティを確保できる点で好ましい形態であるが、３者間の通信のすべてをこの方式で行うことは必須ではない。例えば、ユーザ機器３０と中間サーバ２１の間は、通信の傍受やなりすましなどのサイバー攻撃のリスクが相対的に高いため、高度なセキュリティが望まれるのに対し、中間サーバ２１とサービス提供サーバ２０の間の通信は、サイバー攻撃のリスクが相対的に低い。したがって、例えば、ユーザ機器３０と中間サーバ２１の間の通信にはＩＣチップを利用した保護を適用し、中間サーバ２１とサービス提供サーバ２０の間の通信は他の方式によりセキュリティを確保してもよい。他の方式としては、例えば、ＩＤとパスワードによる方式、アクセストークンによる方式、ＩＣチップとは異なる暗号化通信による方式、サーバ間を専用線で接続する方式などがある。以下に、それぞれの方式の一例を説明する。
　（１）ＩＤとパスワードによる方式
　（初回登録）
　図２２を参照して、中間サービスへの初回登録手続を説明する。図２２は、中間サービスへの登録手続の流れを示す。なお、この段階では、中間サーバ２１が提供する中間サービスへのユーザ登録とサービス提供サーバ２０が提供するオンラインサービスへのユーザ登録は既に済んでおり、中間サーバ２１が提供するサービスにログインするためのＩＤとパスワード（以後、便宜的に「ユーザＩＤ１」、「パスワード１」と記す）、及び、サービス提供サーバ２０が提供するサービスにログインするためのＩＤとパスワード（以後、便宜的に「ユーザＩＤ２」、「パスワード２」と記す）はユーザに付与されているものとする。
　まず、ユーザは、ユーザ機器３０を操作し、本体アプリ６０のダウンロード及びインストールを行う（ステップＳ２１００）。そして、ユーザは、本体アプリ６０を起動し、中間サーバ２１のログイン画面を開く（ステップＳ２１０１）。初回のログイン時には、ユーザがログイン画面において中間サーバ２１へのユーザＩＤ１とパスワード１を入力し、ユーザ機器３０がユーザＩＤ１とパスワード１とともにログイン要求を中間サーバ２１に送信する（ステップＳ２１０２）。このとき、本体アプリ６０は、中間サーバ２１へのユーザＩＤ１を不揮発性メモリに記憶する（ステップＳ２１０３）。パスワード１については、セキュリティの観点からユーザ機器３０には記憶させないほうがよい。なお、中間サーバ２１へのユーザＩＤ１とパスワード１は、別途の手続である中間サービスの新規利用申込を行ったときに、中間サービス提供者から付与される情報である。
　ユーザＩＤ１とパスワード１を中間サーバ２１が検証し、ログインが完了すると（ステップＳ２１０４）、中間サーバ２１は、所定の電文（内容はどのようなものでもよい）をユーザ機器３０に送信し、電子署名と電子証明書を要求する（ステップＳ２１０５）。
　本体アプリ６０のユーザ認証部６０１は、ＰＩＮコード入力画面を表示する。ユーザによりＰＩＮコードが入力されると、ユーザ認証部６０１は、ＩＣチップの認証機能６２０を利用して、入力されたＰＩＮコードが正しいか否かを確認する（ステップＳ２１０６）。ＰＩＮコードが正しい場合（つまり、ユーザ認証に成功した場合）は、本体アプリ６０からＩＣチップの他の機能を利用可能となる。本体アプリ６０のセキュリティ処理部６０２は、ＩＣチップの電子署名機能６２２を利用して、中間サーバ２１から受信した電文に電子署名を行うと共に、電子証明書読出機能６２７を利用して、メモリから電子証明書を読み出す。そして、本体アプリ６０のメイン処理部６００は、電子署名付き電文と電子証明書を中間サーバ２１に送信する（ステップＳ２１０７）。
　中間サーバ２１は、ユーザ機器３０から受信した電子証明書を用いて電子署名付き電文を検証する（ステップＳ２１０８）。検証に成功した場合、中間サーバ２１は、当該ユーザの中間サーバ２１へのユーザＩＤ１と電子証明書を紐付けて、ユーザ情報記憶部２１１に登録する（ステップＳ２１０９）。そして、中間サーバ２１は、電子証明書の登録が完了した旨を本体アプリ６０へ通知する（ステップＳ２１１０）。中間サーバ２１への登録が完了すると、ユーザ機器３０にはメニュー画面が表示される（ステップＳ２１１１）。
　（中間サービスへのログイン）
　図２３を参照して、中間サービスのログイン認証を説明する。図２３は、中間サービスのログイン認証の流れを示す。
　ユーザが、ユーザ機器３０において本体アプリ６０を起動すると、ユーザ認証部６０１が、ＰＩＮコード入力画面を表示する（ステップＳ２２００）。ユーザによりＰＩＮコードが入力されると、ユーザ認証部６０１は、ＩＣチップの認証機能６２０を利用して、入力されたＰＩＮコードが正しいか否かを確認する（ステップＳ２２０１）。ＰＩＮコードが正しい場合（つまり、ユーザ認証に成功した場合）、本体アプリ６０のセキュリティ処理部６０２は、ＩＣチップの電子署名機能６２２を利用して、中間サーバ２１へのユーザＩＤ１と認証用電文に対し電子署名を行う（ステップＳ２２０２）。そして、本体アプリ６０のメイン処理部６００は、ログイン要求を中間サーバ２１に送信する（ステップＳ２２０３）。ログイン要求には、中間サーバ２１へのユーザＩＤ１、サービス提供サーバ２０へのユーザＩＤ２とパスワード２、認証用電文、電子署名が付加されている。
　中間サーバ２１のログイン制御部２１２は、ログイン要求を受信すると、ログイン要求に含まれる中間サーバ２１へのユーザＩＤ１に基づいて、ユーザ情報記憶部２１１から対応する電子証明書を読み出し、この電子証明書を用いて、ログイン要求に含まれている電子署名の検証を行う（ステップＳ２２０４）。また、必要に応じて、ログイン制御部２１２は、電子証明書の有効性を認証局に問い合わせてもよい（ステップＳ２２０５、Ｓ２２０６）。電子署名の検証に成功し、且つ、電子証明書の有効性が確認された場合、ログイン制御部２１２は、ログイン要求が正当なユーザからのものであると判断し、サービス提供サーバ２０へのユーザＩＤ２とパスワード２を当該ユーザの中間サーバ２１へのユーザＩＤ１と紐付けて、ユーザ情報記憶部２１１に登録する（ステップＳ２２０７）。
　続いて、中間サーバ２１のログイン制御部２１２は、サービス提供サーバ２０にアクセス要求を送信する（ステップＳ２２０８）。このアクセス要求には、サービス提供サーバ２０へのユーザＩＤ２とパスワード２が付加されている。
　サービス提供サーバ２０のアクセス制御部２０２は、アクセス要求を受信すると、サービス提供サーバ２０へのユーザＩＤ２とパスワード２の検証を行う（ステップＳ２２０９）。ユーザＩＤ２とパスワード２の検証に成功した場合、アクセス制御部２０２は、このアクセス要求が、ユーザから代行権限が与えられた中間サーバ２１からのものであると判断し、中間サーバ２１に対しアクセス許可を与える（ステップＳ２２１０）。
　オンラインサービスのアクセス許可が得られたら、中間サーバ２１は、ログイン認証ＯＫを本体アプリ６０に通知する（ステップＳ２２１１）。以後、ユーザ機器３０に中間サービスのメニュー画面が表示され、ユーザは希望する手続を行うことができるようになる（ステップＳ２２１２）。
　以上述べた処理によれば、物理的なトークンを用いる方法に比べて、非常に簡便な操作で中間サービス及びオンラインサービスの利用が可能となる。
　（オンラインサービスの利用）
　図２４を参照して、中間サービス利用時の手順を説明する。図２４は、中間サービス利用時の流れを示す図である。中間サービスへのログインは既に完了しており、ユーザ機器３０にはメニュー画面が表示されているものとする。
　ユーザがメニュー画面から利用したい手続を選択すると、詳細画面に遷移する（ステップＳ２３００）。この詳細画面においてユーザが必要な情報（例えば振込先、振込額など）を入力し、実行ボタンを押すと（ステップＳ２３０１）、本体アプリ６０のメイン処理部６００が、振込手続に必要な情報を記述した手続メッセージを作成する（ステップＳ２３０２）。
　続いて、本体アプリ６０のユーザ認証部６０１が、ＰＩＮコード入力画面を表示し、ＰＩＮコード認証を行う（ステップＳ２３０３）。ＰＩＮコード認証の手順は前述したものと同様のため、説明を省略する。ＰＩＮコード認証に成功した場合、本体アプリ６０のセキュリティ処理部６０２は、ＩＣチップの電子署名機能６２２を利用して、手続メッセージに対し電子署名を行う（ステップＳ２３０４）。このとき、電子署名機能６２２は、手続メッセージのハッシュ値を計算し、このハッシュ値を秘密鍵で暗号化することにより電子署名を生成してもよいし、手続メッセージ自体を秘密鍵で暗号化することにより電子署名を生成してもよい。そして、本体アプリ６０のメイン処理部６００は、手続要求を中間サーバ２１に送信する（ステップＳ２３０５）。手続要求には、中間サーバ２１へのユーザＩＤ１、手続メッセージ、電子署名が付加されている。
　中間サーバ２１の代行制御部２１３は、手続要求を受信すると、手続要求に含まれるユーザの中間サーバへのユーザＩＤ１に基づいて、ユーザ情報記憶部２１１から対応する電子証明書を読み出し、この電子証明書を用いて、手続要求に含まれている電子署名の検証を行う（ステップＳ２３０６）。また、必要に応じて、代行制御部２１３は、電子証明書の有効性を認証局に問い合わせてもよい（ステップＳ２３０７、Ｓ２３０８）。電子署名の検証に成功し、且つ、電子証明書の有効性が確認された場合、代行制御部２１３は、手続要求が正当なユーザからのものであると判断する。すなわち、第三者によるなりすましがなく、かつ、手続メッセージの内容も改ざんされていないと判断するのである。
　手続要求が正当なユーザからのものであると確認できた場合、代行制御部２１３は、当該ユーザのサービス提供サーバ２０へのユーザＩＤ２とパスワード２を読み出し、サービス提供サーバ２０に手続要求を送信する（ステップＳ２３０９）。この手続要求には、ユーザ機器３０から受信した手続メッセージ及び電子署名が付加されている。
　サービス提供サーバ２０の手続制御部２０３は、手続要求を受信すると、ユーザＩＤ２とパスワード２の検証を行う（ステップＳ２３１０）。ユーザＩＤ２とパスワード２の検証に成功した場合、手続制御部２０３は、この手続要求が正当なユーザからのものであると判断する。すなわち、第三者によるなりすましがなく、かつ、手続メッセージの内容も改ざんされていないと判断するのである
　手続要求が正当なユーザからのものであると確認できた場合にのみ、手続制御部２０３は、手続メッセージに記述された情報に基づく手続（振込など）を実行する（ステップＳ２３１１）。手続が完了すると、手続制御部２０３は手続完了通知を中間サーバ２１に送信し、中間サーバ２１が手続完了通知を本体アプリ６０に送信する（ステップＳ２３１２、Ｓ２３１３）。そうすると、手続完了画面が表示される。
　以上述べた処理によれば、物理的なトークンを用いる方法などに比べて、非常に簡便な操作で中間サービス及びオンラインサービスの利用が可能となる。
　（２）アクセストークンによる方式
　次に、アクセストークンを用いて中間サーバ２１からサービス提供サーバ２０へのアクセス権限の認可をする方式について、一例を示す。
　（初回登録）
　図２５及び図２６を参照して、中間サービスへの初回登録手続を説明する。中間サーバ２１にユーザの電子証明書を登録する手順（ステップＳ２４００～Ｓ２４１０）は、図２２で説明した手順（ステップＳ２１００～Ｓ２１１０）と同様のため、説明を割愛する。電子証明書の登録完了後、アクセストークン発行のための認可コードの発行とアクセストークンの発行が行われる。アクセストークンとは、中間サーバ２１がユーザに代わりオンラインサービスを利用する際の認可証のようなものである。本実施形態では、ＯＡｕｔｈ２．０の仕組みを利用して、中間サーバ２１によるオンラインサービスの代行を実現する。
　まず、認可コードの発行を行うため、登録完了通知を受け取ったのちユーザ機器３０は、中間サーバ２１へのユーザＩＤ１、サービス提供サーバ２０へのユーザＩＤ２とパスワード２、電子署名付き電文、電子証明書を中間サーバ２１に送信する（ステップＳ２４１１）。中間サーバ２１はユーザ機器３０から受信した電子証明書を用いて電子署名付き電文を検証する（ステップＳ２４１２）。検証に成功した場合、中間サーバ２１のユーザ登録部２００はサービス提供サーバ２０へのユーザＩＤ２と中間サーバ２１へのユーザＩＤ１を紐付けて、ユーザ情報記憶部２１１に登録する（ステップＳ２４１３）。その後、中間サーバ２１は、ユーザ機器３０から受信したサービス提供サーバ２０へのユーザＩＤ２・パスワード２とあわせて認可コードの発行要求をサービス提供サーバ２０に送信する（ステップＳ２４１４）。サービス提供サーバ２０は中間サーバ２１から受信したユーザＩＤ２・パスワード２を検証し、検証に成功した場合、サービス提供サーバ２０は受信したユーザＩＤ２に紐づく、アクセストークンを発行するための認可コードを発行する（ステップＳ２４１５）。サービス提供サーバ２０は、中間サーバ２１に、ユーザＩＤ２及び認可コードとともに認証結果を送信する（ステップＳ２４１６）。中間サーバ２１は受信したサービス提供サーバ２０へのユーザＩＤ２を中間サーバ２１へのユーザＩＤ１に変換し、認可コードと認証結果をユーザ機器３０に送信する（ステップＳ２４１７）。ユーザ機器３０は中間サーバ２１へのユーザＩＤ１及び認可コードとあわせてアクセストークン発行要求を中間サーバ２１に送信する（ステップＳ２４１８）。中間サーバ２１は受信した中間サーバ２１へのユーザＩＤ１をサービス提供サーバ２０へのユーザＩＤ２に変換し、ユーザＩＤ２と認可コードとアクセストークン発行要求をサービス提供サーバ２０に送信する（ステップＳ２４１９）。サービス提供サーバ２０は当該ユーザと中間サービスの組に対し、アクセストークンを発行する（ステップＳ２４２０）。ユーザ登録部２００は、発行したアクセストークンとサービス提供サーバ２０へのユーザＩＤ２を紐付けて、ユーザ情報記憶部２０１に登録する。
　そして、サービス提供サーバ２０は、サービス提供サーバ２０へのユーザＩＤ２と発行したアクセストークンを中間サーバ２１に送信する（ステップＳ２４２１）。中間サーバ２１は受け取ったアクセストークンと当該ユーザの中間サーバ２１へのユーザＩＤ１とを紐付けて、ユーザ情報記憶部２１１に登録する（ステップＳ２４２２）。なお、図示しないが、中間サーバ２１はサービス提供サーバ２０からアクセストークンと共にリフレッシュトークンも受け取る。リフレッシュトークンは、アクセストークンの再発行に利用されるトークンである。これはＯＡｕｔｈ２．０の仕様であるため、ここでは詳しい説明は割愛する。
　その後、中間サーバ２１は、アクセストークンの発行が完了した通知を本体アプリ６０へ通知し、ユーザ機器３０にはメニュー画面が表示される（ステップＳ２４２３、Ｓ２４２４）。
　（中間サービスへのログイン）
　中間サービスへのログインではアクセストークンの検証を行う。図２７に、中間サービスへのログイン処理の流れを示す。図２７のステップＳ２６００～Ｓ２６０６の処理は、図２３のステップＳ２２００～Ｓ２２０６の処理とほぼ同様である。ただし、本例では、ログイン要求に付加される情報が、中間サーバ２１へのユーザＩＤ１と認証用電文と電子署名である点が、図２３の処理とは相違する。
　中間サーバ２１は、電子署名の正当性と電子証明書の有効性を確認したのち、サービス提供サーバ２０にアクセス要求を送信する（ステップＳ２６０７）。このとき、中間サーバ２１は、ログイン要求に含まれる中間サーバ２１へのユーザＩＤ１に基づいて、ユーザ情報記憶部２１１からサービス提供サーバ２０へのユーザＩＤ２とオンラインサービスのアクセストークンを読み出し、アクセス要求とともに送信する。
　サービス提供サーバ２０のアクセス制御部２０２は、アクセス要求を受信すると、アクセス要求に含まれるサービス提供サーバ２０へのユーザＩＤ２とアクセストークンの検証を行う（ステップＳ２６０８）。検証に成功した場合、アクセス制御部２０２は、アクセス要求がユーザから代行権限が与えられた中間サーバ２１からのものであると判断し、中間サーバ２１に対しアクセス許可を与える（ステップＳ２６０９）。
　オンラインサービスのアクセス許可が得られたら、中間サーバ２１は、ログイン認証ＯＫを本体アプリ６０に通知する（ステップＳ２６１０）。以後、ユーザ機器３０に中間サービスのメニュー画面が表示され、ユーザは希望する手続を行うことができようになる（ステップＳ２６１１）。
　以上述べた処理によれば、物理的なトークンを用いる方法に比べて、非常に簡便な操作で中間サービス及びオンラインサービスの利用が可能となる。
　（オンラインサービスの利用）
　オンラインサービスでも、アクセストークンの検証を行う。図２８に、オンラインサービスの処理の流れを示す。図２８のステップＳ２７００～Ｓ２７０８の処理は、図２４のステップＳ２３００～Ｓ２３０８の処理と同様である。
　電子証明書によって手続要求が正当なユーザからのものであると確認できた場合、中間サーバ２１の代行制御部２１３は、サービス提供サーバ２０に手続要求を送信する（ステップＳ２７０９）。このとき、代行制御部２１３は、ユーザ機器３０から受信したユーザＩＤ１に基づいて、ユーザ情報記憶部２１１から対応するサービス提供サーバ２０へのユーザＩＤ２とオンラインサービスのアクセストークンを読み出し、サービス提供サーバ２０に手続要求を送信する（ステップＳ２７０９）。この手続要求には、アクセストークンと、ユーザ機器３０から受信した手続メッセージ及び電子署名とが付加されている。
　サービス提供サーバ２０の手続制御部２０３は、手続要求を受信すると、手続要求に含まれるサービス提供サーバ２０へのユーザＩＤ２とアクセストークンの検証を行う（ステップＳ２７１０）。検証に成功した場合、手続制御部２０３はこの手続要求が正当なユーザからのものであると判断する。
　手続要求が正当なユーザからのものであると確認できた場合にのみ、手続制御部２０３は、手続メッセージに記述された情報に基づく手続（振込など）を実行する（ステップＳ２７１１）。手続が完了すると、手続制御部２０３は手続完了通知を中間サーバ２１に送信し（ステップＳ２７１２）、中間サーバ２１が手続完了通知を本体アプリ６０に送信する（ステップＳ２７１３）。手続完了通知を受信したユーザ機器３０には、手続完了画面が表示される。
　以上述べた処理によれば、物理的なトークンを用いる方法に比べて、非常に簡便な操作で中間サービス及びオンラインサービスの利用が可能となる。
　（３）ＩＣチップとは異なる暗号化通信による方式
　中間サーバ２１とサービス提供サーバ２０の間の通信を、ＩＣチップによる暗号化通信とは異なる方式で、暗号化してもよい。例えば、中間サーバ２１とサービス提供サーバ２０の間で共通鍵を共有し、中間サーバ２１とサービス提供サーバ２０の間の通信を共通鍵で暗号化してもよい。あるいは、中間サーバ２１とサービス提供サーバ２０の間の通信を公開鍵暗号方式によって暗号化してもよい。また、ＳＳＬ／ＴＬＳ、ＩＰｓｅｃなどの暗号化通信を利用してもよい。
　このような暗号化通信による方式の場合も、ユーザはＰＩＮコードを入力するだけでよいので、従来の方法に比べて、非常に簡便な操作で中間サービス及びオンラインサービスの利用が可能となる。なお、（３）の暗号化通信は、（１）のユーザＩＤとパスワードを利用する方式や、（２）のアクセストークンを利用する方式と組み合わせてもよい。
　（４）サーバ間を専用線で接続する方式
　専用線の仕組みを利用して、中間サーバ２１とサービス提供サーバ２０の間のセキュアな通信を実現することもできる。専用線とは、独占的に使用できる通信回線のことである。中間サーバ２１とサービス提供サーバ２０の間に物理的な専用線を設けてもよいし、仮想的な専用線（ＶＰＮ）を利用してもよい。
　このような専用線を利用する方式の場合も、ユーザはＰＩＮコードを入力するだけでよいので、従来の方法に比べて、非常に簡便な操作で中間サービス及びオンラインサービスの利用が可能となる。なお、（４）の専用線は、（１）のユーザＩＤとパスワードを利用する方式や、（２）のアクセストークンを利用する方式や、（３）の暗号化通信による方式と組み合わせてもよい。
　＜サーバの多段接続＞
　上述した各実施形態では、ユーザ機器３０と中間サーバ２１とサービス提供サーバ２０の３者間の通信について説明したが、本発明は、中間サーバ２１及び／又はサービス提供サーバ２０を多段接続した構成に対して適用することもできる。
　図２９Ａは、ユーザ機器３０とサービス提供サーバ２０の間に２つ以上の中間サーバ２１Ａ、２１Ｂが従属的（直列的）に接続される構成を示している。例えば、第一の中間サーバ２１Ａは銀行サービスと連携して家計簿や資産管理のような付加価値サービスを提供する企業（Ｆｉｎｔｅｃｈ企業と呼ばれる）のサーバであり、第二の中間サーバ２１ＢはＦｉｎｔｅｃｈ企業と銀行の間に介在して、電子証明書による検証やユーザの管理などの代行を行うサーバであり、サービス提供サーバ２０はオンラインバンキングサービスを提供する銀行システムである。電子証明書による検証やユーザの管理などの処理の一部又は全部をサービス提供サーバ２０から切り離し、別の中間サーバ２１Ｂで代行する構成とすることで、サービス提供サーバ２０の導入や運用が容易になると期待される。このような形態は、例えば、複数の銀行のサービス提供サーバ２０の電子証明書やユーザの管理を、一つの中間サーバ２１Ｂで集中的に代行する、というような場合に有利である。また、図２９Ａの構成は、Ｆｉｎｔｅｃｈ企業の中間サーバ２１Ａが、他のＦｉｎｔｅｃｈ企業の中間サーバ２１Ｂのサービスを利用する場合にも適用できる。例えば、個々のＦｉｎｔｅｃｈ企業が提供するサービスを束ねて統合的なＦｉｎｔｅｃｈサービスを提供することが想定される。
　図２９Ｂは、２つ以上のサービス提供サーバ２０Ａ、２０Ｂが直列的に接続される構成である。この構成は、例えば、ある銀行から他の銀行に送金する場合、銀行のサーバと証券のサーバとが連携する場合などに適用できる。
　図２９Ｃは、２つ以上の中間サーバ２１Ａ、２１Ｂと２つ以上のサービス提供サーバ２０Ａ、２０Ｂが直列的に接続される構成の例である。なお、中間サーバ２１及びサービス提供サーバ２０の接続数は任意である。以下に中間サーバが２つ、サービス提供サーバが１つの場合の動作について説明する。
　（初回登録）
　図３０を参照して、中間サービスへの初回登録手続を説明する。図３０は、中間サービスへの登録手続の流れを示す。なお、この段階では、中間サーバＡ（２１Ａ）が提供する中間サービスへのユーザ登録とサービス提供サーバ２０が提供するオンラインサービスへのユーザ登録は既に済んでおり、中間サーバＡが提供するサービスにログインするためのＩＤとパスワード（以後、便宜的に「ユーザＩＤ１」、「パスワード１」と記す）、及び、サービス提供サーバ２０が提供するサービスにログインするためのＩＤとパスワード（以後、便宜的に「ユーザＩＤ２」、「パスワード２」と記す）はユーザに付与されているものとする。なお、この例では、中間サーバＡ（２１Ａ）と中間サーバＢ（２１Ｂ）が協働してユーザに中間サービスを提供しており、ユーザは、中間サーバが多段接続されていることを意識することはない。
　まず、ユーザは、ユーザ機器３０を操作し、本体アプリ６０のダウンロード及びインストールを行う（ステップＳ２９００）。そして、ユーザは、本体アプリ６０を起動し、中間サーバＡのログイン画面を開く（ステップＳ２９０１）。初回のログイン時には、ログイン画面において中間サーバＡへのユーザＩＤ１とパスワード１を入力し、ユーザ機器３０がユーザＩＤ１とパスワード１とともにログイン要求を中間サーバＡに送信する。このとき、本体アプリは、中間サーバＡへのユーザＩＤ１を不揮発性メモリに記憶する（ステップＳ２９０３）。パスワード１については、セキュリティの観点からユーザ機器３０には記憶させないほうがよい。なお、中間サーバＡへのユーザＩＤ１とパスワード１は、別途の手続である中間サービスの新規利用申込を行ったときに、中間サービス提供者から付与される情報である。
　中間サーバＡがユーザＩＤ１とパスワード１を検証し、中間サーバＡへのログインが完了すると（ステップＳ２９０４）、中間サーバＡは、ユーザ機器３０から受信したユーザＩＤ１とパスワード１を中間サーバＢに送信する（ステップＳ２９０５）。同様に、中間サーバＢがユーザＩＤ１とパスワード１を検証し、中間サーバＢへのログインが完了すると（ステップＳ２９０６）、中間サーバＢは所定の電文（内容はどのようなものでもよい）を中間サーバＡに送信し、電子署名と電子証明書を要求する（ステップＳ２９０７）。中間サーバＡは中間サーバＢから受信した所定の電文をユーザ機器３０に送信する（ステップＳ２９０８）。
　本体アプリ６０のユーザ認証部６０１は、ＰＩＮコード入力画面を表示する。ユーザによりＰＩＮコードが入力されると、ユーザ認証部６０１は、ＩＣチップの認証機能６２０を利用して、入力されたＰＩＮコードが正しいか否かを確認する（ステップＳ２９０９）。ＰＩＮコードが正しい場合（つまり、ユーザ認証に成功した場合）は、本体アプリ６０からＩＣチップの他の機能を利用可能となる。本体アプリ６０のセキュリティ処理部６０２は、ＩＣチップの電子署名機能６２２を利用して、中間サーバＡから受信した電文に電子署名を行うと共に、電子証明書読出機能６２７を利用して、メモリから電子証明書を読み出す。そして、本体アプリ６０のメイン処理部６００は、電子署名付き電文と電子証明書を中間サーバＡに送信する（ステップＳ２９１０）。
　中間サーバＡは、ユーザ機器３０から受信した電子署名付き電文と電子証明書を中間サーバＢに送信する（ステップＳ２９１１）とともに、その電子証明書を用いて電子署名付き電文を検証する（ステップＳ２９１２）。検証に成功した場合、中間サーバＡは、当該ユーザのユーザＩＤ１と電子証明書を紐付けて、ユーザ情報記憶部に登録する（ステップＳ２９１３）。
　同様に、中間サーバＢも、電子証明書を用いて電子署名付き電文を検証する（ステップＳ２９１４）。検証に成功した場合、中間サーバＢは、当該ユーザのユーザＩＤ１と電子証明書を紐付けて、ユーザ情報記憶部に登録する（ステップＳ２９１６）。そして、中間サーバＢは、電子証明書の登録が完了した旨を中間サーバＡへ通知する（ステップＳ２９１６）。これを受けて、中間サーバＡは、電子証明書の登録が完了した旨を本体アプリ６０へ通知する（ステップＳ２９１７）。中間サービスへの登録が完了すると、ユーザ機器３０にはメニュー画面が表示される。
　（中間サービスへのログイン）
　図３１及び図３２を参照して、中間サービスのログイン認証を説明する。図３１及びず３１は、中間サービスのログイン認証の流れを示す。
　ユーザが、ユーザ機器３０において本体アプリ６０を起動すると、ユーザ認証部６０１が、ＰＩＮコード入力画面を表示する（ステップＳ３０００）。ユーザによりＰＩＮコードが入力されると、ユーザ認証部６０１は、ＩＣチップの認証機能６２０を利用して、入力されたＰＩＮコードが正しいか否かを確認する（ステップＳ３００１）。ＰＩＮコードが正しい場合（つまり、ユーザ認証に成功した場合）、本体アプリ６０のセキュリティ処理部６０２は、ＩＣチップの電子署名機能６２２を利用して、中間サーバＡへのユーザＩＤ１と認証用電文に対し電子署名を行う（ステップＳ３００２）。そして、本体アプリ６０のメイン処理部６００は、ログイン要求を中間サーバＡに送信する（ステップＳ３００３）。ログイン要求には、中間サーバＡへのユーザＩＤ１、サービス提供サーバ２０へのユーザＩＤ２とパスワード２、認証用電文、電子署名が付加されている。
　中間サーバＡのログイン制御部２１２は、ログイン要求を受信すると、ログイン要求に含まれる中間サーバＡへのユーザＩＤ１に基づいて、ユーザ情報記憶部２１１から対応する電子証明書を読み出し、この電子証明書を用いて、ログイン要求に含まれている電子署名の検証を行う（ステップＳ３００４）。また、必要に応じて、ログイン制御部２１２は、電子証明書の有効性を認証局に問い合わせてもよい（ステップＳ３００５、Ｓ３００６）。電子署名の検証に成功し、且つ、電子証明書の有効性が確認された場合、ログイン制御部２１２は、ログイン要求が正当なユーザからのものであると判断する。
　続いて、中間サーバＡのログイン制御部２１２は、ログイン要求を中間サーバＢに送信する（ステップＳ３００７）。ログイン要求には、ユーザＩＤ１、ユーザＩＤ２とパスワード２、認証用電文、電子署名が付加されている。
　中間サーバＢのログイン制御部２１２は、ログイン要求を受信すると、ログイン要求に含まれるユーザＩＤ１に基づいて、ユーザ情報記憶部２１１から対応する電子証明書を読み出し、この電子証明書を用いて、ログイン要求に含まれている電子署名の検証を行う（ステップＳ３００８）。また、必要に応じて、ログイン制御部２１２は、電子証明書の有効性を認証局に問い合わせてもよい（ステップＳ３００９、Ｓ３０１０）。電子署名の検証に成功し、且つ、電子証明書の有効性が確認された場合、ログイン制御部２１２は、ログイン要求が正当なユーザからのものであると判断し、サービス提供サーバ２０へのユーザＩＤ２とパスワード２を当該ユーザの中間サーバＡへのユーザＩＤ１と紐付けて、ユーザ情報記憶部２１１に登録する（ステップＳ３０１１）。
　続いて、中間サーバＢのログイン制御部２１２は、サービス提供サーバ２０にアクセス要求を送信する（ステップＳ３０１２）。このアクセス要求には、サービス提供サーバ２０へのユーザＩＤ２とパスワード２が付加されている。
　サービス提供サーバ２０のアクセス制御部２０２は、アクセス要求を受信すると、サービス提供サーバ２０へのユーザＩＤ２とパスワード２の検証を行う（ステップＳ３０１３）。サービス提供サーバ２０へのユーザＩＤ２とパスワード２の検証に成功した場合、アクセス制御部２０２は、このアクセス要求が、ユーザから代行権限が与えられた中間サーバからのものであると判断し、中間サーバＢに対しアクセス許可を与える（ステップＳ３０１４）。
　オンラインサービスのアクセス許可が得られたら、中間サーバＢは、ログイン認証ＯＫを中間サーバＡに通知し（ステップＳ３０１５）、さらに中間サーバＡは、ログイン認証ＯＫを本体アプリ６０に通知する（ステップＳ３０１６）。以後、ユーザ機器３０に中間サービスのメニュー画面が表示され、ユーザは希望する手続を行うことができるようになる（ステップＳ３０１７）。
　以上述べた処理によれば、物理的なトークンを用いる方法に比べて、非常に簡便な操作で中間サービス及びオンラインサービスの利用が可能となる。
　（オンラインサービスの利用）
　図３３及び図３４を参照して、中間サービス利用時の手順を説明する。図３３及び図３４は、中間サービス利用時の流れを示す図である。中間サービスへのログインは既に完了しており、ユーザ機器にはメニュー画面が表示されているものとする。
　ユーザがメニュー画面から利用したい手続を選択すると、詳細画面に遷移する（ステップＳ３２００）。この詳細画面においてユーザが必要な情報（例えば振込先、振込額など）を入力し、実行ボタンを押すと（ステップＳ３２０１）、本体アプリ６０のメイン処理部６００が、振込手続に必要な情報を記述した手続メッセージを作成する（ステップＳ３２０２）。
　続いて、本体アプリ６０のユーザ認証部６０１が、ＰＩＮコード入力画面を表示し、ＰＩＮコード認証を行う（ステップＳ３２０３）。ＰＩＮコード認証の手順は前述したものと同様のため、説明を省略する。ＰＩＮコード認証に成功した場合、本体アプリ６０のセキュリティ処理部６０２は、ＩＣチップの電子署名機能６２２を利用して、手続メッセージに対し電子署名を行う（ステップＳ３２０４）。このとき、電子署名機能６２２は、手続メッセージのハッシュ値を計算し、このハッシュ値を秘密鍵で暗号化することにより電子署名を生成してもよいし、手続メッセージ自体を秘密鍵で暗号化することにより電子署名を生成してもよい。そして、本体アプリ６０のメイン処理部６００は、手続要求を中間サーバＡに送信する（ステップＳ３２０５）。手続要求には、中間サーバＡへのユーザＩＤ１、手続メッセージ、電子署名が付加されている。
　中間サーバＡの代行制御部２１３は、手続要求を受信すると、手続要求に含まれるユーザの中間サーバへのユーザＩＤ１に基づいて、ユーザ情報記憶部２１１から対応する電子証明書を読み出し、この電子証明書を用いて、手続要求に含まれている電子署名の検証を行う（ステップＳ３２０６）。また、必要に応じて、中間サーバＡの代行制御部２１３は、電子証明書の有効性を認証局に問い合わせてもよい（ステップＳ３２０７、Ｓ３２０８）。電子署名の検証に成功し、且つ、電子証明書の有効性が確認された場合、中間サーバＡの代行制御部２１３は、手続要求が正当なユーザからのものであると判断する。すなわち、第三者によるなりすましがなく、かつ、手続メッセージの内容も改ざんされていないと判断するのである。
　手続要求が正当なユーザからのものであると確認できた場合、中間サーバＡの代行制御部２１３は、中間サーバＢに手続要求を送信する（ステップＳ３２０９）。この手続要求には、ユーザＩＤ１、手続メッセージ、電子署名が付加されている。
　中間サーバＢの代行制御部２１３は、手続要求を受信すると、手続要求に含まれるユーザＩＤ１に基づいて、ユーザ情報記憶部２１１から対応する電子証明書を読み出し、この電子証明書を用いて、手続要求に含まれている電子署名の検証を行う（ステップＳ３２１０）。また、必要に応じて、中間サーバＢの代行制御部２１３は、電子証明書の有効性を認証局に問い合わせてもよい（ステップＳ３２１１、Ｓ３２１２）。電子署名の検証に成功し、且つ、電子証明書の有効性が確認された場合、中間サーバＢの代行制御部２１３は、手続要求が正当なユーザからのものであると判断する。すなわち、第三者によるなりすましがなく、かつ、手続メッセージの内容も改ざんされていないと判断するのである。
　手続要求が正当なユーザからのものであると確認できた場合、中間サーバＢの代行制御部２１３は、サービス提供サーバ２０へのユーザＩＤ２とパスワード２を読み出し、サービス提供サーバ２０に手続要求を送信する（ステップＳ３２１３）。この手続要求には、ユーザ機器３０から受信した手続メッセージ及び電子署名が付加されている。
　サービス提供サーバ２０の手続制御部２０３は、手続要求を受信すると、ユーザＩＤ２とパスワード２の検証を行う（ステップＳ３２１４）。ユーザＩＤ２とパスワード２の検証に成功した場合、手続制御部２０３は、この手続要求が正当なユーザからのものであると判断する。すなわち、第三者によるなりすましがなく、かつ、手続メッセージの内容も改ざんされていないと判断するのである
　手続要求が正当なユーザからのものであると確認できた場合にのみ、手続制御部２０３は、手続メッセージに記述された情報に基づく手続（振込など）を実行する（ステップＳ３２１５）。手続が完了すると、手続制御部２０３は手続完了通知を中間サーバＢに送信し（ステップＳ３２１６）、中間サーバＢが中間サーバＡに手続完了通知を送信し（ステップＳ３２１７）、中間サーバＡが手続完了通知を本体アプリ６０に送信する（ステップＳ３２１８）。そうすると、手続完了画面が表示される。
　上述した各実施形態において、ユーザ機器３０が各サーバや認証局との間でインターネットを介したデータ通信を行う場合には、ユーザ機器３０が備える通信用のＳＩＭカードのＩＭＳＩ又はそのＩＭＳＩに対応付けられたＩＰアドレスによって、データの送信元あるいは送信先としてのＳＩＭカード（すなわちユーザ機器３０）が特定される。ＩＰアドレスは、動的に割り当てられるＩＰアドレスであってもよいし、固定のＩＰアドレスであってもよい。
２０：サービス提供サーバ
２１：中間サーバ
３０：ユーザ機器
６０：アプリケーションプログラム
７０：ＩＣカード発行端末
３０６：ＳＩＭカード
３０７：ＩＣカード（サブＳＩＭ）
３０８：ＳＩＭカードスロット

Claims (26)

  1. 　サービス提供者が提供するオンラインサービスを、前記サービス提供者とは異なる者が提供する中間サービスを介して、携帯機器から安全に利用可能な仕組みを提供するオンラインサービス提供システムであって、
    　登録されたユーザに対し、インターネットを通じて前記オンラインサービスを提供するサービス提供サーバと、
    　前記ユーザに対し、インターネットを通じて前記中間サービスを提供する中間サーバと、
    　前記ユーザが所持している携帯機器であるユーザ機器に設けられるＩＣチップと、
    　前記ユーザ機器が有する本体プロセッサにより実行され、前記ユーザ機器を前記中間サービスを利用するための端末として機能させるアプリケーションプログラムと、を有し、
    　前記ＩＣチップは、
    　　少なくとも、前記ユーザ機器を使用する者の正当性を確認するためのユーザ認証に用いられる本人情報、前記ユーザの秘密鍵、前記秘密鍵とペアになる前記ユーザの公開鍵、及び、前記公開鍵を含む前記ユーザの電子証明書を非一時的に記憶するメモリと、
    　　少なくとも、前記アプリケーションプログラムから与えられる情報を前記本人情報と照合することにより前記ユーザ認証を行う認証機能、及び、前記アプリケーションプログラムから与えられるデータに対し前記秘密鍵を用いた電子署名を行う電子署名機能を有するプロセッサと、
    を有しており、
    　前記アプリケーションプログラムは、前記ユーザ機器を、
    　　前記ユーザ機器を使用する者から取得した情報に基づき、前記ＩＣチップの前記認証機能を利用して、前記ユーザ認証を行うユーザ認証手段、及び、
    　　前記ユーザ認証により前記ユーザ機器を使用する者が正当であると確認された場合に、前記ＩＣチップの前記電子署名機能を利用して電子署名を生成し、生成された前記電子署名を含むログイン要求をインターネットを通じて前記中間サーバに送信する送信手段、として機能させ、
    　前記中間サーバは、
    　　前記ユーザに関する情報として、前記ユーザの電子証明書を記憶するユーザ情報記憶手段と、
    　　前記ユーザ機器から前記ログイン要求を受信した場合に、前記ユーザの電子証明書を用いて前記ログイン要求に含まれる前記電子署名を検証することによって前記ログイン要求の正当性を確認し、前記ログイン要求が正当であると確認された場合に前記ユーザ機器からの前記中間サービスの利用を許可すると共に、アクセス要求を前記サービス提供サーバに送信する制御手段と、
    を有し、
    　前記サービス提供サーバは、
    　　前記中間サーバから前記アクセス要求を受信した場合に、前記アクセス要求の正当性を確認し、前記アクセス要求が正当であると確認された場合に前記中間サーバによる前記オンラインサービスの利用を許可するアクセス制御手段と、
    を有することを特徴とするオンラインサービス提供システム。
  2. 　前記中間サーバの前記制御手段は、前記ログイン要求に含まれる前記電子署名とともに前記アクセス要求を前記サービス提供サーバに送信し、
    　前記サービス提供サーバは、前記ユーザの電子証明書を用いて前記電子署名を検証することによって前記アクセス要求の正当性を確認する
    ことを特徴とする請求項１に記載のオンラインサービス提供システム。
  3. 　前記中間サーバの前記制御手段は、前記ユーザのユーザＩＤ及びパスワードとともに前記アクセス要求を前記サービス提供サーバに送信し、
    　前記サービス提供サーバは、前記ユーザの前記ユーザＩＤ及び前記パスワードを検証することによって前記アクセス要求の正当性を確認する
    ことを特徴とする請求項１に記載のオンラインサービス提供システム。
  4. 　前記中間サーバの前記制御手段は、前記ユーザのユーザＩＤと前記サービス提供サーバが予め発行したアクセストークンとともに前記アクセス要求を前記サービス提供サーバに送信し、
    　前記サービス提供サーバは、前記ユーザの前記ユーザＩＤ及び前記アクセストークンを検証することによって前記アクセス要求の正当性を確認する
    ことを特徴とする請求項１に記載のオンラインサービス提供システム。
  5. 　前記送信手段は、前記ユーザ認証により前記ユーザ機器を使用する者が正当であると確認された場合に、前記ＩＣチップの前記電子署名機能を利用して、前記オンラインサービスの手続に必要な情報を記述したメッセージに対し電子署名を行い、電子署名付きメッセージを含む手続要求をインターネットを通じて前記中間サーバに送信し、
    　前記中間サーバは、前記ユーザ機器から前記手続要求を受信した場合に、前記ユーザの電子証明書を用いて前記手続要求に含まれる前記電子署名付きメッセージを検証することによって前記手続要求の正当性を確認し、前記手続要求が正当であると確認された場合に前記手続要求に含まれる前記メッセージを含む手続実行要求を前記サービス提供サーバに送信し、
    　前記サービス提供サーバは、前記中間サーバから前記手続実行要求を受信した場合に、前記手続実行要求の正当性を確認し、前記手続実行要求が正当であると確認された場合に前記手続実行要求に含まれる前記メッセージに記述された情報に基づく手続を実行する
    ことを特徴とする請求項１～４のいずれかに記載のオンラインサービス提供システム。
  6. 　前記中間サーバは、前記電子署名付きメッセージを含む前記手続実行要求を前記サービス提供サーバに送信し、
    　前記サービス提供サーバは、前記ユーザの電子証明書を用いて前記手続実行要求に含まれる前記電子署名付きメッセージを検証することによって前記手続実行要求の正当性を確認する
    ことを特徴とする請求項５に記載のオンラインサービス提供システム。
  7. 　前記送信手段は、前記サービス提供サーバの公開鍵を用いて前記メッセージを暗号化した後、前記ＩＣチップの前記電子署名機能を利用して前記暗号化されたメッセージに対し電子署名を行う
    ことを特徴とする請求項６に記載のオンラインサービス提供システム。
  8. 　前記中間サーバは、前記ユーザのユーザＩＤ及びパスワードとともに前記手続実行要求を前記サービス提供サーバに送信し、
    　前記サービス提供サーバは、前記ユーザの前記ユーザＩＤ及び前記パスワードを検証することによって前記手続実行要求の正当性を確認する
    ことを特徴とする請求項５に記載のオンラインサービス提供システム。
  9. 　前記中間サーバは、前記ユーザのユーザＩＤと前記サービス提供サーバが予め発行したアクセストークンとともに前記手続実行要求を前記サービス提供サーバに送信し、
    　前記サービス提供サーバは、前記ユーザの前記ユーザＩＤ及び前記アクセストークンを検証することによって前記手続実行要求の正当性を確認する
    ことを特徴とする請求項５に記載のオンラインサービス提供システム。
  10. 　前記中間サーバと前記サービス提供サーバとの間の通信が暗号化されている
    ことを特徴とする請求項１～９のいずれかに記載のオンラインサービス提供システム。
  11. 　前記中間サーバと前記サービス提供サーバとの間が専用線で接続される
    ことを特徴とする請求項１～１０のいずれかに記載のオンラインサービス提供システム。
  12. 　前記中間サーバは、多段接続された複数の中間サーバから構成される
    ことを特徴とする請求項１～１１のいずれかに記載のオンラインサービス提供システム。
  13. 　前記ＩＣチップは、通信用のＳＩＭカード上に重ねて貼り付けられた状態でＳＩＭカードスロットに装着されるものである
    ことを特徴とする請求項１～１２のいずれかに記載のオンラインサービス提供システム。
  14. 　前記ＩＣチップは、通信用のＳＩＭカードである
    ことを特徴とする請求項１～１２のいずれかに記載のオンラインサービス提供システム。
  15. 　前記ＩＣチップは、セキュアエレメントである
    ことを特徴とする請求項１～１２のいずれかに記載のオンラインサービス提供システム。
  16. 　前記ＩＣチップの前記メモリは、外部からのアクセスが不可能なエリアを有しており、
    　少なくとも前記本人情報及び前記秘密鍵は、外部からのアクセスが不可能な前記エリア内に格納されている
    ことを特徴とする請求項１～１５のいずれかに記載のオンラインサービス提供システム。
  17. 　前記ＩＣチップの前記プロセッサは、前記秘密鍵と前記公開鍵を生成する鍵生成機能を有している
    ことを特徴とする請求項１～１６のいずれかに記載のオンラインサービス提供システム。
  18. 　前記ＩＣチップは、前記ＩＣチップを一意に特定しうる識別情報を有しており、
    　前記ユーザ機器と前記中間サーバ及び／又は前記サービス提供サーバとの間で、前記識別情報により前記ＩＣチップが特定された通信が行われる
    ことを特徴とする請求項１～１７のいずれかに記載のオンラインサービス提供システム。
  19. 　前記アプリケーションプログラムは、前記中間サーバ及び／又は前記サービス提供サーバと前記ＩＣチップとの対応付けを行う対応付け情報を有しており、前記対応付け情報に基づいて、前記中間サーバ及び／又は前記サービス提供サーバとの通信において利用する前記ＩＣチップを特定する
    ことを特徴とする請求項１～１７のいずれかに記載のオンラインサービス提供システム。
  20. 　前記ユーザ機器と前記中間サーバ及び／又は前記サービス提供サーバとの間で、前記ユーザ機器が備える通信用のＳＩＭカードのＩＭＳＩ又はそのＩＭＳＩに対応付けられたＩＰアドレスにより前記ＳＩＭカードが特定された通信が行われる
    ことを特徴とする請求項１～１９のいずれかに記載のオンラインサービス提供システム。
  21. 　前記ユーザ機器が有する本体プロセッサにより実行され、前記ＩＣチップをセットアップするための機能を提供するセットアッププログラムを有している
    ことを特徴とする請求項１～２０のいずれかに記載のオンラインサービス提供システム。
  22. 　前記セットアッププログラムは、前記ユーザ機器を、
    　認証局に対して電子証明書の発行要求を送信する手段、および、
    　前記認証局より前記電子証明書を受信し、前記ＩＣチップの前記メモリに前記電子証明書を格納する手段、
    として機能させる
    ことを特徴とする請求項２１に記載のオンラインサービス提供システム。
  23. 　前記セットアッププログラムは、前記ユーザ機器を、
    　前記ユーザ機器が備える通信用のＳＩＭカードから電話番号及び／又はＩＭＳＩを読み出す手段、
    　前記電話番号及び／又はＩＭＳＩを前記認証局に通知するための手段、
    　前記認証局から前記電話番号又は前記ＩＭＳＩにより特定される宛先に送信された情報を受信する手段、
    として機能させる
    ことを特徴とする請求項２２に記載のオンラインサービス提供システム。
  24. 　前記情報は、ＳＭＳにより前記ユーザ機器に送信される
    ことを特徴とする請求項２３に記載のオンラインサービス提供システム。
  25. 　前記情報は、インターネットを介したデータ通信により前記ユーザ機器に送信される
    ことを特徴とする請求項２３に記載のオンラインサービス提供システム。
  26. 　ユーザが所持している携帯機器であるユーザ機器が有する本体プロセッサにより実行され、前記ユーザ機器を、サービス提供サーバがインターネットを通じて提供するオンラインサービスを前記サービス提供サーバとは異なる中間サーバが提供する中間サービスを介して利用するための端末として機能させるアプリケーションプログラムであって、
    　前記ユーザ機器には、
    　　少なくとも、前記ユーザ機器を使用する者の正当性を確認するためのユーザ認証に用いられる本人情報、前記ユーザの秘密鍵、前記秘密鍵とペアになる前記ユーザの公開鍵、及び、前記公開鍵を含む前記ユーザの電子証明書を非一時的に記憶するメモリと、
    　　少なくとも、前記アプリケーションプログラムから与えられる情報を前記本人情報と照合することにより前記ユーザ認証を行う認証機能、及び、前記アプリケーションプログラムから与えられるデータに対し前記秘密鍵を用いた電子署名を行う電子署名機能を有するプロセッサと、
    を有するＩＣチップが設けられており、
    　前記アプリケーションプログラムは、前記ユーザ機器を、
    　　前記ユーザ機器を使用する者から取得した情報に基づき、前記ＩＣチップの前記認証機能を利用して、前記ユーザ認証を行うユーザ認証手段、及び、
    　　前記ユーザ認証により前記ユーザ機器を使用する者が正当であると確認された場合に、前記ＩＣチップの前記電子署名機能を利用して電子署名を生成し、生成された前記電子署名を含むログイン要求をインターネットを通じて前記中間サーバに送信する送信手段、として機能させることを特徴とするアプリケーションプログラム。
PCT/JP2019/025434 2018-06-26 2019-06-26 オンラインサービス提供システム、アプリケーションプログラム WO2020004486A1 (ja)

Priority Applications (4)

Application Number Priority Date Filing Date Title
JP2020527589A JP7469756B2 (ja) 2018-06-26 2019-06-26 オンラインサービス提供システム
US17/255,455 US11617084B2 (en) 2018-06-26 2019-06-26 Online service providing system and application program
EP19825083.9A EP3817278A4 (en) 2018-06-26 2019-06-26 ONLINE SERVICE DELIVERY SYSTEM AND APPLICATION PROGRAM
JP2023222237A JP2024024011A (ja) 2018-06-26 2023-12-28 オンラインサービス提供システム、アプリケーションプログラム

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2018-121031 2018-06-26
JP2018121031 2018-06-26

Publications (1)

Publication Number Publication Date
WO2020004486A1 true WO2020004486A1 (ja) 2020-01-02

Family

ID=68986599

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2019/025434 WO2020004486A1 (ja) 2018-06-26 2019-06-26 オンラインサービス提供システム、アプリケーションプログラム

Country Status (4)

Country Link
US (1) US11617084B2 (ja)
EP (1) EP3817278A4 (ja)
JP (2) JP7469756B2 (ja)
WO (1) WO2020004486A1 (ja)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP7470313B2 (ja) * 2018-06-26 2024-04-18 日本通信株式会社 オンラインサービス提供システム
US11477026B1 (en) * 2019-08-21 2022-10-18 Riverbed Technology, Inc. Using secure tokens for stateless software defined networking
JP7262378B2 (ja) * 2019-12-05 2023-04-21 株式会社日立製作所 認証認可システムおよび認証認可方法
EP4203387A1 (de) * 2021-12-22 2023-06-28 Deutsche Telekom AG Verfahren und system zur authentifizierung eines endgeräts eines nutzers

Citations (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH10177552A (ja) * 1996-12-17 1998-06-30 Fuji Xerox Co Ltd 認証応答方法およびその方法を用いた認証応答装置
JP2003298574A (ja) * 2002-03-29 2003-10-17 Toshiba Corp 電子機器、認証局、電子機器認証システム、電子機器の認証方法
JP2007058455A (ja) * 2005-08-23 2007-03-08 Dainippon Printing Co Ltd アクセス管理システム、および、アクセス管理方法
WO2007094035A1 (ja) * 2006-02-13 2007-08-23 Seiko Instruments Inc. 検証サーバ機器
JP2009217722A (ja) * 2008-03-12 2009-09-24 Nippon Telegr & Teleph Corp <Ntt> 認証処理システム、認証装置、管理装置、認証処理方法、認証処理プログラムおよび管理処理プログラム
JP2009237774A (ja) * 2008-03-26 2009-10-15 Advanced Media Inc 認証サーバ、サービス提供サーバ、認証方法、通信端末、およびログイン方法
JP2012048728A (ja) 2011-09-20 2012-03-08 Sandisk Il Ltd 個人の存在を条件とする、トークンによるトランザクション認証
JP2014010486A (ja) * 2012-06-27 2014-01-20 Ntt Docomo Inc 情報処理装置及び認可情報管理方法
JP2016071538A (ja) 2014-09-29 2016-05-09 株式会社日立製作所 認証システム
WO2017022121A1 (ja) * 2015-08-06 2017-02-09 三菱電機株式会社 認証装置、認証システム、及び認証方法
JP2017157984A (ja) * 2016-02-29 2017-09-07 Kddi株式会社 通信システム、ハードウェアセキュリティモジュール、端末装置、通信方法、及びプログラム

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FI116654B (fi) 2003-10-23 2006-01-13 Siltanet Ltd Menetelmä käyttäjän autentikoimiseksi
US7559468B2 (en) 2004-05-24 2009-07-14 Panasonic Corporation Reader/writer secure module access control method
US7613915B2 (en) 2006-11-09 2009-11-03 BroadOn Communications Corp Method for programming on-chip non-volatile memory in a secure processor, and a device so programmed
WO2009126994A1 (en) * 2008-04-14 2009-10-22 Lockstep Technologies Pty Ltd Authenticating electronic financial transactions
IT1396776B1 (it) 2009-11-11 2012-12-14 Sisvel Technology Srl Dispositivo e metodo di comunicazione in una rete di comunicazione mobile
WO2011110539A1 (en) 2010-03-08 2011-09-15 Gemalto Sa System and method for using a portable security device to cryptographically sign a document in response to signature requests from a relying party to a digital signature service
CN102054258A (zh) * 2010-12-16 2011-05-11 中国建设银行股份有限公司 一种基于移动设备的电子银行安全认证方法及系统
US9325683B2 (en) * 2012-06-18 2016-04-26 Infosys Limited Mobile application management framework
US10528946B2 (en) * 2013-11-06 2020-01-07 Tencent Technology (Shenzhen) Company Limited System and method for authenticating, associating and storing secure information
US9392457B2 (en) * 2013-11-27 2016-07-12 Cellco Partnership Method and apparatus for self-activating a mobile device
US20160048688A1 (en) * 2014-08-14 2016-02-18 Google Inc. Restricting System Calls using Protected Storage

Patent Citations (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH10177552A (ja) * 1996-12-17 1998-06-30 Fuji Xerox Co Ltd 認証応答方法およびその方法を用いた認証応答装置
JP2003298574A (ja) * 2002-03-29 2003-10-17 Toshiba Corp 電子機器、認証局、電子機器認証システム、電子機器の認証方法
JP2007058455A (ja) * 2005-08-23 2007-03-08 Dainippon Printing Co Ltd アクセス管理システム、および、アクセス管理方法
WO2007094035A1 (ja) * 2006-02-13 2007-08-23 Seiko Instruments Inc. 検証サーバ機器
JP2009217722A (ja) * 2008-03-12 2009-09-24 Nippon Telegr & Teleph Corp <Ntt> 認証処理システム、認証装置、管理装置、認証処理方法、認証処理プログラムおよび管理処理プログラム
JP2009237774A (ja) * 2008-03-26 2009-10-15 Advanced Media Inc 認証サーバ、サービス提供サーバ、認証方法、通信端末、およびログイン方法
JP2012048728A (ja) 2011-09-20 2012-03-08 Sandisk Il Ltd 個人の存在を条件とする、トークンによるトランザクション認証
JP2014010486A (ja) * 2012-06-27 2014-01-20 Ntt Docomo Inc 情報処理装置及び認可情報管理方法
JP2016071538A (ja) 2014-09-29 2016-05-09 株式会社日立製作所 認証システム
WO2017022121A1 (ja) * 2015-08-06 2017-02-09 三菱電機株式会社 認証装置、認証システム、及び認証方法
JP2017157984A (ja) * 2016-02-29 2017-09-07 Kddi株式会社 通信システム、ハードウェアセキュリティモジュール、端末装置、通信方法、及びプログラム

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP3817278A4

Also Published As

Publication number Publication date
US11617084B2 (en) 2023-03-28
EP3817278A4 (en) 2022-03-16
JP2024024011A (ja) 2024-02-21
US20210297862A1 (en) 2021-09-23
EP3817278A1 (en) 2021-05-05
JP7469756B2 (ja) 2024-04-17
JPWO2020004486A1 (ja) 2021-07-08

Similar Documents

Publication Publication Date Title
JP7469756B2 (ja) オンラインサービス提供システム
KR101544722B1 (ko) 부인 방지 방법, 이를 위한 결제 관리 서버 및 사용자 단말기
WO2009039771A1 (fr) Terminal de paiement mobile et procédé de paiement basé sur la technologie pki
WO2018014760A1 (zh) 图形码信息提供、获取方法、装置及终端
CN101841525A (zh) 安全接入方法、系统及客户端
CN102195932A (zh) 一种基于两个隔离设备实现网络身份认证的方法和系统
KR100939725B1 (ko) 모바일 단말기 인증 방법
KR102012262B1 (ko) 키 관리 방법 및 ｆｉｄｏ 소프트웨어 인증장치
US20170154329A1 (en) Secure transaction system and virtual wallet
KR101656458B1 (ko) 본인 확인 및 본인 인증을 위한 인증 방법 및 시스템
CN104333452A (zh) 一种对文件数据多账户加密的方法
JP6499368B1 (ja) オンラインサービス提供システム
JP4409497B2 (ja) 秘密情報送信方法
KR101771484B1 (ko) 보안 토큰을 효율적으로 사용하기 위한 서명 키 생성방법
JP6499367B1 (ja) オンラインサービス提供システム
KR100905315B1 (ko) 모바일 환경에서의 공인인증서 서비스 방법
JP4372403B2 (ja) 認証システム
JP6499369B1 (ja) オンラインサービス提供システム
WO2020004494A1 (ja) オンラインサービス提供システム、ｉｃチップ、アプリケーションプログラム
WO2020004495A1 (ja) オンラインサービス提供システム、アプリケーションプログラム
KR101639794B1 (ko) 본인 확인 및 본인 인증을 위한 인증 방법 및 시스템
KR101394147B1 (ko) 모바일에서 안전하게 인증서를 사용하는 방법
KR20160150164A (ko) 공인인증서 관리회사 기반의 간편 결제 시스템 및 이를 이용한 간편 결제 방법
WO2022223520A1 (en) Data management system implemented in a mobile device
KR20140025773A (ko) 해외 인터넷뱅킹 제한 서비스 방법

Legal Events

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

Ref document number: 19825083

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2020527589

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2019825083

Country of ref document: EP

Effective date: 20210126