JP6012125B2 - Enhanced 2CHK authentication security through inquiry-type transactions - Google Patents

Enhanced 2CHK authentication security through inquiry-type transactions Download PDF

Info

Publication number
JP6012125B2
JP6012125B2 JP2015516019A JP2015516019A JP6012125B2 JP 6012125 B2 JP6012125 B2 JP 6012125B2 JP 2015516019 A JP2015516019 A JP 2015516019A JP 2015516019 A JP2015516019 A JP 2015516019A JP 6012125 B2 JP6012125 B2 JP 6012125B2
Authority
JP
Japan
Prior art keywords
user
website
security
transaction
application
Prior art date
Legal status (The legal status 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 status listed.)
Active
Application number
JP2015516019A
Other languages
English (en)
Other versions
JP2015526784A (ja
Inventor
ピーター・ジョージ・タプリング
アンドリュー・ロバート・ロルフ
ラヴィ・ガネサン
サリー・シュワード
Original Assignee
オーセンティファイ・インクAuthentify Inc.
オーセンティファイ・インクAuthentify Inc.
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
Priority to US13/490,715 priority Critical
Priority to US13/490,715 priority patent/US9716691B2/en
Application filed by オーセンティファイ・インクAuthentify Inc., オーセンティファイ・インクAuthentify Inc. filed Critical オーセンティファイ・インクAuthentify Inc.
Priority to PCT/US2013/039684 priority patent/WO2013184267A1/en
Publication of JP2015526784A publication Critical patent/JP2015526784A/ja
Application granted granted Critical
Publication of JP6012125B2 publication Critical patent/JP6012125B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/04Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31User authentication
    • G06F21/34User authentication involving the use of external additional devices, e.g. dongles or smart cards
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31User authentication
    • G06F21/42User authentication using separate channels for security data
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/08Network architectures or network communication protocols for network security for supporting authentication of entities communicating through a packet data network
    • H04L63/0823Network architectures or network communication protocols for network security for supporting authentication of entities communicating through a packet data network using certificates
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/08Network architectures or network communication protocols for network security for supporting authentication of entities communicating through a packet data network
    • H04L63/0853Network architectures or network communication protocols for network security for supporting authentication of entities communicating through a packet data network using an additional device, e.g. smartcard, SIM or a different communication terminal
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/18Network architectures or network communication protocols for network security using different networks or paths for security, e.g. using out of band channels
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communication
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communication 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/3226Cryptographic mechanisms or cryptographic arrangements for secret or secure communication 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
    • H04L9/3228One-time or temporary data, i.e. information which is sent for every authentication or authorization, e.g. one-time-password, one-time-token or one-time-key
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communication
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communication 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/3247Cryptographic mechanisms or cryptographic arrangements for secret or secure communication 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
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communication
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communication 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/3271Cryptographic mechanisms or cryptographic arrangements for secret or secure communication 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 challenge-response

Description

本発明は、セキュリティおよびプライバシに関する。より具体的には、本発明は、デスクトップおよび/またはラップトップコンピュータと互換性のあるハードウェア・プラグイン・デバイス、および/またはApple iPhones(商標)等のスマートモバイル通信デバイスを用いる、ウェブベースの署名を含むウェブベースのログインおよびトランザクション認証に関する。   The present invention relates to security and privacy. More specifically, the present invention provides a web-based device that uses a hardware plug-in device compatible with desktop and / or laptop computers, and / or smart mobile communication devices such as Apple iPhones ™. For web-based login and transaction authentication including signatures.

パスワード、ワンタイムパスワード(OTP)、ハードウェアまたはソフトウェアスマートカード、他の技術を用いるユーザ認証は、全て、弱体に過ぎており、中間者(MITM)攻撃またはマンインザブラウザ(MITB)攻撃を受けやすいことが分かっているか、そうでなくとも扱いにくく高価すぎることが分かっている。OpenID、FaceBook Connect、他等の技術に単一の署名を使用することは、攻撃者が、一旦マスターアカウントに不正侵入すると、次にはこの初回ログインに依存する他の全てのアカウントへ侵入できることから、問題を悪化させるだけである。さらに、攻撃者の焦点は、ログイン処理を破壊することから、高度な技術を用いて、ログイン行為後に侵入し、実行されているトランザクションを攻撃することへと移行している。これにより、トランザクション認証、即ちバックエンドのウェブサーバにおいて検分されるトランザクションがユーザの意図するものと同一であるかどうかを確認する行為、がますます重要となっている。   User authentication using passwords, one-time passwords (OTP), hardware or software smart cards, and other technologies are all weak and vulnerable to man-in-the-middle (MITM) or man-in-the-browser (MITB) attacks. It turns out that it's known or otherwise too cumbersome and expensive. The use of a single signature for technologies such as OpenID, FaceBook Connect, etc. means that once an attacker has hacked into a master account, it can then break into all other accounts that rely on this initial login. It only exacerbates the problem. Furthermore, the focus of attackers has shifted from destroying login processing to using advanced techniques to invade after a login attempt and attack executed transactions. As a result, transaction authentication, that is, the act of confirming whether or not the transaction to be examined in the back-end web server is the same as the user's intention is becoming increasingly important.

帯域外認証(OOBA)、即ちユーザへトランザクションを中継し、かつ代替形式の通信、例えば音声電話呼またはテキストメッセージの送信を用いて確認を得る技術は、有望な代替技術であるが、同じく頻繁に用いるには不便かつ高価すぎる。これは、極めて重要なトランザクションまたはパスワードの再設定のようなめったにない事象には有用である場合もあるが、大量のトランザクションに用いるには高価かつ煩雑すぎる。   Out-of-band authentication (OOBA), a technique that relays transactions to the user and obtains confirmation using alternative forms of communication, such as sending a voice telephone call or text message, is a promising alternative technique, but also frequently Inconvenient and expensive to use. This may be useful for rare events such as critical transactions or password resets, but is too expensive and cumbersome to use for high volume transactions.

最近では、これらの問題点のうちの幾つかに対処する革新的な新しい認証システムおよびプロトコルが開発されている。具体的には、一般に「2CHK」と称されるシステムおよびプロトコルは、ユーザに、ウェブサイトへログインできるようにする(即ち、ウェブサイトに対するユーザの認証)、または、ウェブサイトとセキュリティサーバとの間で共有される秘密に基づいて、入力されたトランザクションにウェブサイトで電子的に署名できるようにするためのOTPを提供することができる。特に有用である点は、2CHKは、ワンタイムパスワードによる安全性を提供するが、先行する全てのOTPシステムおよびプロトコルが要求しているユーザ毎の共有秘密鍵を要求しない、という事実にある。   Recently, innovative new authentication systems and protocols have been developed that address some of these issues. Specifically, a system and protocol commonly referred to as “2CHK” allows a user to log in to a website (ie, authenticating the user to the website) or between the website and the security server. An OTP may be provided to allow an entered transaction to be electronically signed at a website based on a secret shared with the Internet. Particularly useful is the fact that 2CHK provides one-time password security, but does not require per-user shared secrets required by all previous OTP systems and protocols.

ユーザが商業者、銀行またはブローカのウェブサイト等の電子商取引ウェブサイトを閲覧する場合、ユーザがPayPalにより提供されるもの等の支払ボタンを目にすることは一般的である。ユーザがこの支払い機能をクリックすると、ユーザは、典型的には、支払いプロバイダと直接に双方向通信している。これは、ユーザは、支払いプロバイダに対して自らを認証するための認証情報を電子商取引サイトへは漏らさないことを意味する。これは、ユーザが、ウェブサイトが提供するスマートフォンアプリを用いて電子商取引サイトと双方向通信しているときには、もはや利用できない重要な特徴である。したがって、2CHKは、バックエンドの認証サーバへの独立した安全な通信チャネルを有する、一般に「2CHKクライアント」と称される別の安全なクライアントアプリケーションを用いて実現することが可能である。2CHKクライアントは、コンピュータ装置上の専用ソフトウェアとして、またはブラウザをベースにしたアプリケーションとして、またはIPhone等のスマートフォンを含む移動体通信デバイス上のアプリケーションとして実現することが可能である。   When a user browses an electronic commerce website such as a merchant, bank or broker website, it is common for the user to see a payment button such as that provided by PayPal. When the user clicks on this payment function, the user is typically in direct two-way communication with the payment provider. This means that the user does not leak authentication information for authenticating himself / herself to the payment provider to the electronic commerce site. This is an important feature that is no longer available when a user is bi-directionally communicating with an e-commerce site using a smartphone app provided by a website. Thus, 2CHK can be implemented using another secure client application, commonly referred to as a “2CHK client”, that has an independent secure communication channel to the backend authentication server. The 2CHK client can be implemented as dedicated software on a computer device, as an application based on a browser, or as an application on a mobile communication device including a smartphone such as IPphone.

例えば、2CHKクライアントは、ユーザにトランザクションを知らせる、ユーザがトランザクションを追認/拒否できるようにする、かつ/またはユーザに、ユーザが商業者または銀行のウェブサイトアプリケーション等の他のアプリケーションにおいてトランザクションを承認するために使用できるトランザクション署名、即ちOTP、を提供する、の何れかを目的として、ユーザトランザクションを示すために使用されることが可能である。さらに、2CHKクライアントは、ユーザに、異なるウェブサイトまたは他のアプリケーションへログインするために使用できるOTPを提供することもできる。実現の仕方に依存して、2CHKは、このようなOTPを生成するための2つの別個の方法のうちの何れかを用いることができる。その一方では、OTPは、認証サーバによって提供され、もう一方では、2CHKクライアントが起動中に「シード付与」され、それによって、これは次に、バックエンド認証サーバとは如何なるつながりも無しでOTPを生成することができる。   For example, the 2CHK client informs the user of the transaction, allows the user to review / reject the transaction, and / or allows the user to approve the transaction in other applications such as a merchant or bank website application. It can be used to indicate a user transaction for the purpose of either providing a transaction signature, or OTP, that can be used for this purpose. In addition, the 2CHK client can also provide the user with an OTP that can be used to log into different websites or other applications. Depending on how it is implemented, 2CHK can use either of two separate methods for generating such an OTP. On the one hand, the OTP is provided by the authentication server, and on the other hand, the 2CHK client is “seeded” during startup, so that this in turn does not connect the OTP without any connection to the backend authentication server. Can be generated.

大量のスマートフォンによって、結果的に、様々なインタフェースを用いてスマートフォンへ取り付けることができる補助的なハードウェア品のマーケットが到来している。USBポートおよび/またはケーブルを用いてコンピュータへプリンタを接続できることに酷似して、スマートフォンへも、例えばどこにでもあるヘッドフォンジャックを用いてデバイスを接続することができる。したがって、2CHKクライアントは、このような補助的ハードウェア上で実行されるように、かつこれにより、スマートモバイル通信デバイスと互換性のあるプラグインハードウェアおよびインターネット接続可能パーソナル・コンピュータ装置を用いて効率的かつ安全なログイン認証およびトランザクション承認を提供するように適合化されている。   The large volume of smartphones has resulted in a market for auxiliary hardware products that can be attached to smartphones using a variety of interfaces. Much like being able to connect a printer to a computer using a USB port and / or cable, a device can also be connected to a smartphone, for example using a headphone jack everywhere. Thus, the 2CHK client is efficient to run on such ancillary hardware and thereby using plug-in hardware and internet-connected personal computer equipment compatible with smart mobile communication devices. It is adapted to provide secure and secure login authentication and transaction authorization.

本発明は、補助的ハードウェアを用いて実現する形態を含む、パーソナル・コンピュータ装置およびiPhoneおよびiPad等のスマートモバイル通信デバイス上での2CHKログイン認証および/またはトランザクション承認の実現において追加的な柔軟性を提供することができる、2CHKシステムおよびプロトコルのさらなる改良、および/または攻撃者に対する保護の強化に関する。   The present invention provides additional flexibility in realizing 2CHK login authentication and / or transaction authorization on personal computer devices and smart mobile communication devices such as iPhone and iPad, including implementations using auxiliary hardware. Further improvements to the 2CHK system and protocol, and / or enhanced protection against attackers.

当業者には、本発明の追加の目的、優位点、新規特徴が、以下の詳細な説明を含む本開示からだけでなく、本発明の実施によっても明らかとなるであろう。以下、本発明を1つまたは複数の好適な実施形態を参照して説明するが、本発明がこれらに限定されないことは理解されるべきである。本明細書における教示を閲覧できる一般的な当業者には、本明細書に開示されかつクレームに記載されている発明の範囲に含まれる、かつ本発明が重要な有用性を有する可能性がある追加的な実施、変更および具現化ならびに他の利用分野が認識されるであろう。   Additional objects, advantages, and novel features of the present invention will become apparent to those skilled in the art not only from this disclosure, including the following detailed description, but also from practice of the invention. The invention will now be described with reference to one or more preferred embodiments, but it should be understood that the invention is not limited thereto. For those of ordinary skill in the art who can view the teachings herein, the scope of the invention disclosed herein and set forth in the claims may be within the scope of the invention, and the invention may have significant utility. Additional implementations, modifications and implementations and other areas of application will be recognized.

本発明の態様によれば、セキュリティサーバは、ユーザ・ネットワーク・デバイスからネットワークを介して、ネットワーク上でユーザ・ネットワーク・デバイスとセキュリティサーバとの間に安全な通信チャネルを起動するというユーザの要求を受信することにより、インターネット等のネットワークを介して問い合わせ型トランザクションを実行するように動作する。これに応答して、セキュリティサーバは、他のネットワークを介してユーザに配信するために起動コードを送信する。例えば、起動コードは、情報の配信に公衆交換電話網または携帯電話網を用いる帯域外認証事業者へ送信される場合もある。このような事業者は、好ましくは、ネットワーク上に代表されるものであるが、必須ではない。一方で、起動コードは、ユーザに手渡しする、または直接聴覚的に配信するために、任意数の方法で郵便事業者、民間宅配便業者またはメッセンジャーサービス業者へ送られる場合もあり、この場合、これらの事業者は、承認コードをユーザに、例えばインターネットであるネットワーク以外で配信することから、帯域外配信事業者となる。   According to an aspect of the present invention, the security server sends a user request to activate a secure communication channel between the user network device and the security server over the network from the user network device. By receiving, it operates to execute an inquiry type transaction via a network such as the Internet. In response, the security server sends an activation code for delivery to the user via another network. For example, the activation code may be transmitted to an out-of-band authentication provider that uses a public switched telephone network or a mobile telephone network for information distribution. Such operators are preferably represented on the network, but are not essential. On the other hand, the activation code may be sent to the postal service provider, private courier service or messenger service service in any number of ways to be handed to the user or delivered directly audibly. Since the approval code is distributed to the user through a network other than the Internet, for example, the provider is an out-of-band distribution service provider.

セキュリティサーバは、次に、ユーザ・ネットワーク・デバイスからネットワークを介して起動コードを受信し、受信された起動コードを送信された起動コードと比較して受信された起動コードを検証し、かつ受信された起動コードの検証に基づいて安全な通信チャネルを起動する。   The security server then receives the activation code from the user network device over the network, compares the received activation code with the transmitted activation code, verifies the received activation code, and is received The secure communication channel is activated based on the verification of the activated activation code.

起動後の任意の時点で、セキュリティサーバは、商業者、銀行またはブローカ、他等の企業を代表するネットワークサイトからネットワークを介して、ユーザへの質問を含む問い合わせを受信することができる。質問の正解は、ユーザおよび企業により事前に合意されている回答である。例えば、企業側の質問は、ワンタイムパスワードまたはトークン認証コードまたは例えばユーザのパスワードであるユーザと企業とに共有される他のタイプの秘密、または例えば自宅住所、電話番号、親友の名前、母親の旧姓、出生地、高等学校名、他であるユーザの個人的な情報等の秘密について尋ねるものであってもよい。セキュリティサーバは、受信された企業側の問い合わせを安全な通信チャネルを介してユーザ・ネットワーク・デバイスへ送信し、これに応答して、送信された企業側の問い合わせに対するユーザの回答をユーザ・ネットワーク・デバイスから安全な通信チャネルを介して受信する。セキュリティサーバは、企業に対してユーザをさらに認証するために、受信されたユーザの回答を企業ネットワークサイトへネットワークを介して送信する。   At any point after startup, the security server can receive inquiries, including questions to the user, over the network from network sites representing companies such as merchants, banks or brokers, etc. The correct answer of the question is an answer that has been agreed in advance by the user and the company. For example, a company question may be a one-time password or token authentication code or other type of secret that is shared between the user and the company, for example the user's password, or home address, phone number, best friend's name, mother's You may ask about secrets, such as a maiden name, a place of birth, a high school name, and other personal information of a user. The security server sends the received corporate inquiry to the user network device via a secure communication channel, and in response, sends the user's answer to the transmitted enterprise inquiry to the user network Receive from the device via a secure communication channel. The security server transmits the received user response to the corporate network site via the network to further authenticate the user to the corporate.

本発明の他の態様によれば、望ましい場合には、セキュリティサーバは、ネットワークを介して企業のネットワークサイトから、(i)送信されたユーザ回答は、企業に受け入れられる、または(ii)送信されたユーザ回答は、企業に受け入れられない、または(iii)企業によるユーザの追加認証が必要である、の何れかの通知を受信してもよい。受信すれば、セキュリティサーバは、受信された通知をユーザ・ネットワーク・デバイスへ安全な通信チャネルを介して送信する。   According to another aspect of the present invention, if desired, the security server can (i) send a user answer accepted by the enterprise or (ii) be sent from the enterprise network site over the network. The user response may receive a notification that either the company is not accepted or (iii) additional authentication of the user by the company is required. If received, the security server sends the received notification to the user network device via a secure communication channel.

所定の実現形態においては、セキュリティサーバは、受信された企業側の問い合わせを音声ストリームおよび画像のうちの少なくとも一方へ組み込む、例えば埋め込むことが有益である場合があり、それによって、送信される企業側の問い合わせは、音声ストリームおよび画像のうちの少なくとも一方へ組み込まれた企業側の問い合わせとなる。好ましくは、音声ストリームは、ユーザによる認識が可能な音声、例えばユーザ自身の声またはよく知られた有名人、例えばフランクリン・D・ルーズベルトまたはジョン・F・ケネディまたはロナルド・レーガンの声、を有する音声ストリームであり、画像は、予め選択された、例えばモナリザの絵等のユーザが知るところの背景を有する画像である。   In certain implementations, it may be beneficial for the security server to incorporate, eg, embed, the received enterprise side query into at least one of the audio stream and the image, whereby the transmitted enterprise side The inquiry is a company inquiry incorporated in at least one of the audio stream and the image. Preferably, the audio stream has audio that is recognizable by the user, such as audio of the user's own voice or a well-known celebrity, such as Franklin D. Roosevelt or John F. Kennedy or Ronald Reagan. It is a stream, and the image is a pre-selected image having a background that the user knows, such as a picture of Mona Lisa.

したがって、ユーザが認識できる音声を有する音声ストリームおよび/またはユーザが知る背景を有する画像へ情報を組み込み、かつこの音声ストリームおよび/または画像を、ネットワークを介してユーザへ送信することにより、情報がネットワークを介してユーザへより安全に伝達され得ることは理解されるべきである。   Accordingly, by incorporating information into an audio stream having audio that can be recognized by the user and / or an image having a background known to the user, and transmitting the audio stream and / or image to the user via the network, the information is transmitted to the network. It should be understood that it can be transmitted more securely to the user via

また、本方法は、典型的には、ネットワークを介する通信を中継する1つまたは複数のポートと、先に述べたことを実行するようにプログラムされた論理、即ち必然ではないが典型的には実行可能なソフトウェア、を備えるプロセッサとを有するサーバによって実現されることも理解されるべきである。   The method also typically includes one or more ports that relay communications over the network and logic programmed to perform the foregoing, i.e., but not necessarily, typically. It should also be understood that it is realized by a server having a processor with executable software.

また、セキュリティサーバは、ユーザ・ネットワーク・デバイスからネットワークを介して、ネットワーク上でユーザ・ネットワーク・デバイスとセキュリティサーバとの間の安全な通信チャネルを起動するためのユーザの要求を受信することにより、ユーザと、商業者、銀行またはブローカ、他等の企業との間のネットワークを介する商取引を安全に処理するように動作することも可能である。これに応答して、セキュリティサーバは、他のネットワークを介してユーザへ配信するために起動コードを、送信する。   The security server also receives a user request to activate a secure communication channel between the user network device and the security server over the network from the user network device over the network, It is also possible to operate to securely process business transactions over a network between a user and a company such as a merchant, bank or broker, etc. In response, the security server sends an activation code for delivery to the user via another network.

この送信に応答して、セキュリティサーバは、ユーザ・ネットワーク・デバイスからネットワークを介して起動コードを受信し、受信された起動コードを送信された起動コードと比較して受信された起動コードを検証し、かつ受信された起動コードの検証に基づいて安全な通信チャネルを起動する。例えば、これに続くユーザ・ネットワーク・デバイスとセキュリティサーバとの間の通信は全て、承認コードに基づいて対称暗号鍵で暗号化されてもよいが、これは、この時点でユーザおよびセキュリティサーバの双方がこのコードを知っていることに起因する。   In response to this transmission, the security server receives the activation code from the user network device over the network and compares the received activation code with the transmitted activation code to verify the received activation code. And activating a secure communication channel based on verification of the received activation code. For example, all subsequent communications between the user network device and the security server may be encrypted with a symmetric encryption key based on the authorization code, but this is not the case for both the user and the security server at this point. Is due to knowing this code.

セキュリティサーバは、次に、ユーザ・ネットワーク・デバイスから安全な通信チャネルを介して、ユーザが開始を希望するトランザクションの相手企業の識別子と、希望するトランザクションの詳細とを含むトランザクション情報を受信する。トランザクションが事実上任意のタイプであり得ることは、理解されるであろう。インターネット等のネットワーク上で実行される一般的なトランザクションには、口座からの送金、株式または債券の購入および製品またはサービスの購入が含まれるが、これらに限定されない。このようなトランザクションのトランザクション詳細には、典型的には、口座番号、製品コード、送金される、または支払われる金額、およびトランザクションを明確に詳述するために適切と見なされる他の情報といった項目が含まれ、それによって、後にユーザと企業との間にユーザが承認した内容に関する紛争は生じない。セキュリティサーバは、このトランザクション情報をネットワーク上で企業を代表するウェブサイトへネットワークを介して送信する。例えば、この企業ウェブサイトへの送信は、企業ウェブサイトとセキュリティサーバとの間に確立された他の安全な通信チャネルを介する場合もある。   The security server then receives transaction information from the user network device via a secure communication channel, including the identifier of the partner company of the transaction that the user wishes to initiate and the details of the desired transaction. It will be appreciated that a transaction can be of virtually any type. Common transactions performed on networks such as the Internet include, but are not limited to, money transfers from accounts, purchases of stocks or bonds, and purchases of products or services. Transaction details for such transactions typically include items such as account number, product code, amount transferred or paid, and other information deemed appropriate to clearly detail the transaction. Included so that there will be no dispute between the user and the company regarding what the user has approved later. The security server transmits this transaction information via the network to a website representing the company on the network. For example, the transmission to the corporate website may be via other secure communication channels established between the corporate website and the security server.

セキュリティサーバは、ウェブサイトから、望ましい場合には前述の他の安全な通信チャネルである可能性もあるネットワークを介して、(i)企業により、トランザクションは、受け入れられた、または(ii)企業により、トランザクションは、拒絶された、または(iii)企業により、有効なトランザクション署名等のユーザの追加認証が要求されている、の何れかの通知を受信する。受信された通知が、トランザクションは受け入れられた、または拒絶された、という通知であれば、セキュリティサーバは、受信された通知をユーザ・ネットワーク・デバイスへ安全な通信チャネルを介して送信する。   The security server is either (i) by the company, the transaction is accepted, or (ii) by the company, from the website, over a network that may be the other secure communication channel mentioned above, if desired. The transaction receives either notification that it has been rejected, or (iii) that the company requires additional authentication of the user, such as a valid transaction signature. If the received notification is a notification that the transaction has been accepted or rejected, the security server sends the received notification to the user network device over a secure communication channel.

トランザクションへの有効なユーザ署名が企業により要求されると、セキュリティサーバは、受信されたトランザクション情報に基づいて、ユーザがトランザクション署名として用いるためのワンタイムパスワードを生成し、かつ生成されたワンタイムパスワードをセキュリティサーバからユーザ・ネットワーク・デバイスへ安全な通信チャネルを介して送信する。ワンタイムパスワードは、好ましくは、セキュリティサーバおよび企業により共有されるがユーザには知られておらず、いかなる特定のユーザにも関連づけられていない秘密にも基づいて生成される。何れにしても、返報として、セキュリティサーバは、ネットワークを介して企業ウェブサイトから、ユーザからの有効に署名されたトランザクションの企業による受信確認を受信し、かつ企業が有効に署名されたトランザクションを受信したという確認をユーザ・ネットワーク・デバイスへ安全な通信チャネルを介して送信する。当然ながら、ユーザ・ネットワーク・デバイスへのワンタイムパスワードの送信と、有効に署名されたトランザクションの受信確認の企業ウェブサイトからの受信との間に、ユーザ・ネットワーク・デバイスは、セキュリティサーバから受信されたワンタイムパスワードを企業ウェブサイトへ、好ましくはネットワークを介して送信する。   When a valid user signature for a transaction is requested by the enterprise, the security server generates a one-time password for the user to use as a transaction signature based on the received transaction information, and the generated one-time password Is transmitted from the security server to the user network device via a secure communication channel. One-time passwords are preferably generated based on secrets that are shared by security servers and businesses but are not known to the user and are not associated with any particular user. In any case, as a return, the security server receives an acknowledgment by the company of a user-signed transaction from the company website over the network, and the company receives a valid-signed transaction. Confirmation of the success is sent to the user network device via a secure communication channel. Of course, between sending the one-time password to the user network device and receiving from the corporate website the receipt of a valid signed transaction receipt, the user network device is received from the security server. The one-time password is transmitted to the corporate website, preferably via the network.

図1は、本発明による2CHKセキュリティシステムの構成要素を示す。FIG. 1 shows the components of a 2CHK security system according to the present invention. 図2は、本発明による、補助的ハードウェアを除く図1のユーザ・コンピュータ装置を示す。FIG. 2 shows the user computer device of FIG. 1 without auxiliary hardware in accordance with the present invention. 図3は、本発明による、補助的ハードウェアが接続されている図1のユーザ・コンピュータ装置を示す。FIG. 3 shows the user computer device of FIG. 1 with ancillary hardware connected in accordance with the present invention.

2CHKシステム
図1を参照すると、2CHKシステムは、好ましくは下記のうちの幾つか、または全てを含む:
・ デスクトップまたはラップトップコンピュータ、スマートフォンまたはスマートパッド等のユーザ・コンピュータ装置100。これは、インターネット等のネットワークへ接続可能であって、キーボード、キーパッド、マウスまたはユーザ入力を入力する他の手段等の入力手段102と、(1)ウィンドウ110、以後「ウェブサイトウィンドウ」と称する、におけるウェブサイトに関連づけられるページ、以後「ウェブサイトページ」と称する、と、(2)ウィンドウ120、以後「セキュリティウィンドウ」と称する、内のセキュリティサーバに関連づけられるページと、(3)任意の所定の時間にユーザ・コンピュータ装置上で実行されている場合のある様々なアプリケーションのうちの何れかに関連づけられる他のページ、を表示できる画面105とを有する。
・ ウェブサイト130。典型的には、ネットワーク上にウェブサイトサーバによって代表され、ユーザはネットワークを介してこれにアクセスすることができ、ユーザがトランザクションにログインしている、またはトランザクションを実行している、もしくはそのログインまたは実行を希望しているウェブサイトであって、場合により、アプリケーション・プログラミング・インタフェース(API)135および鍵管理ロジック−API(KMLWS)137を含む。実用的な実現形態では、典型的には、ネットワークを介してアクセス可能な複数の異なるウェブサイトが存在することとなることは理解されるべきである。
・ ネットワークを介してユーザがアクセスでき、かつ場合により鍵管理ロジック−サーバ(KMLS)147を含むセキュリティサーバ140。
・ 帯域外認証サーバ150。以後、「OOBAサーバ」と称する。
・ 認証局(CA)170。
・ 例えば従来型の固定電話である有線デバイス、または例えば携帯電話もしくはスマートフォンであるモバイルデバイス、他等のユーザ通信デバイス160。
・ ネットワークを介して確立される、ウェブサイト130とウェブサイトウィンドウ110との間で情報を伝達するための通信チャネル132。
・ ネットワークまたは他の手段を介して確立される、ウェブサイト130とセキュリティサーバ140との間で直接に情報を伝達するための任意選択の安全な通信チャネル134。
・ ネットワークを介して確立される、セキュリティサーバ140とウェブサイトウィンドウ110との間で情報を伝達するための通信チャネル142。
・ ネットワークを介して確立される、セキュリティサーバ140とセキュリティウィンドウ120との間で情報を伝達するための安全な通信チャネル144。
・ ネットワークまたは他の手段を介して確立される、セキュリティサーバ140とOOBAサーバ150との間で情報を伝達するための安全な通信チャネル146。
・ ネットワークまたは他の手段を介して確立される、セキュリティサーバ140とCA170との間で情報を伝達するための安全な通信チャネル148。
・ ネットワーク以外によって確立される、OOBAサーバ150とユーザ通信デバイス160との間で情報を伝達するための通信チャネル152。
2CHK System Referring to FIG. 1, the 2CHK system preferably includes some or all of the following:
A user computer device 100 such as a desktop or laptop computer, a smartphone or a smart pad. This is connectable to a network such as the Internet, and is referred to as an input means 102 such as a keyboard, keypad, mouse or other means for inputting user input, and (1) a window 110, hereinafter referred to as a “website window”. , A page associated with a website, hereinafter referred to as a “website page”, (2) a window 120, hereinafter referred to as a “security window”, a page associated with a security server, and (3) any predetermined And a screen 105 capable of displaying other pages associated with any of a variety of applications that may be running on the user computer device at the same time.
-Website 130. Typically, represented by a website server on the network, the user can access it over the network, and the user is logged into or executing a transaction, or the login or A website that wishes to execute and optionally includes an application programming interface (API) 135 and a key management logic-API (KMLWS) 137. It should be understood that in a practical implementation, there will typically be a number of different websites accessible via the network.
A security server 140 that is accessible to the user via the network and optionally includes a key management logic-server (KMLS) 147;
Out-of-band authentication server 150. Hereinafter, it is referred to as “OOBA server”.
• Certificate Authority (CA) 170.
A user communication device 160 such as a wired device, eg a conventional landline phone, or a mobile device eg a mobile phone or a smartphone, etc.
A communication channel 132 for communicating information between the website 130 and the website window 110, established via the network.
An optional secure communication channel 134 for communicating information directly between the website 130 and the security server 140, established via a network or other means.
A communication channel 142 for communicating information between the security server 140 and the website window 110, established over the network.
A secure communication channel 144 for communicating information between the security server 140 and the security window 120, established over the network.
A secure communication channel 146 for communicating information between the security server 140 and the OOBA server 150, established via a network or other means.
A secure communication channel 148 for communicating information between the security server 140 and the CA 170, established via a network or other means.
A communication channel 152 for communicating information between the OOBA server 150 and the user communication device 160, established by other than the network.

図2を参照すると、ユーザ・コンピュータ装置100は、好ましくは下記のうちの幾つか、または全てを含む:
・ 中央処理装置(CPU)205。
・ ネットワークを介してウェブサイト130およびセキュリティサーバと通信するための、モデムおよびポート等のネットワーク通信デバイス(NCD)206。
・ (1)ウェブサイトウィンドウ110として機能するブラウザウィンドウを生成し、かつウェブサイト130および他のウェブサイト(不図示)から送信されるウェブサイトページを生成してウェブサイトウィンドウ110に表示するためと、(2)セキュリティウィンドウ120として機能するブラウザ・ポップアップ・ウィンドウを生成し、かつセキュリティサーバ140から送信されるページを生成してこのポップアップ・セキュリティ・ウィンドウ120に表示するために、CPU205によって実行されることが可能なウェブ・ブラウザ・アプリケーション207。ブラウザ207により表示されるウェブサイトページは、以後、ウェブページと称される場合がある。
・ セキュリティウィンドウ120を作成し、かつ、セキュリティサーバ140から送信されるページを生成しかつ2CHKセキュリティウィンドウ120に表示するためにCPU205によって実行されることが可能なセキュリティアプリケーション210。以後、「2CHKクライアントアプリケーション」と称される場合もある。セキュリティアプリケーション210は、鍵管理ロジック−クライアント(KMLC)213を含んでもよい。
・ メモリおよび/またはハード・ドライブ・データ・ストアに実現されてもよい、プライベートストア210aおよび212aとパブリックストア210bとを含むローカルストレージ。
・ (1)ウェブサイトウィンドウ110を生成し、かつ、ウェブサイト130に関連づけられるウェブサイトページを生成しかつウェブサイトウィンドウ110に表示するためにCPU205によって実行されることが可能な、商業者または銀行アプリケーション等のウェブサイトアプリケーション212。実用的な実現形態では、各々がネットワークを介してアクセス可能な異なるウェブサイトに関連づけられる複数の異なるウェブサイトアプリケーションが存在し得ることは理解されるべきである。
・ テキストメッセージ送信のためのショート・メッセージ・サービス(SMS)アプリケーション214。以後、「SMSA」と称されることがある。
・ ネットワークを介してeメールを送受信するためのeメールアプリケーション216。
・ コンピュータ装置上で作成される、またはネットワークを介してコンピュータ装置へ送信される文書を生成しかつウィンドウ(不図示)に表示するためにCPU205によって実行されることが可能な、Adobe AcrobatまたはMicrosoft Word等の文書処理アプリケーション218。実用的な実現形態では、複数の異なる文書処理アプリケーションが存在し得ることは理解されるべきである。
・ 補助的ハードウェア上で実行されるセキュリティアプリケーションとセキュリティサーバ140との間の通信のための安全なパイプラインを作成するためにCPU205によって実行されることが可能なプロキシアプリケーション。以後、「2CHKプロキシ・クライアント・アプリケーション」と称される場合もある。
・ コンピュータ装置100を補助的ハードウェアへ通信可能に接続するためのポート222。
Referring to FIG. 2, the user computing device 100 preferably includes some or all of the following:
Central processing unit (CPU) 205.
A network communication device (NCD) 206, such as a modem and port, for communicating with the website 130 and the security server over the network.
(1) To generate a browser window that functions as the website window 110 and generate a website page transmitted from the website 130 and another website (not shown) and display it on the website window 110 (2) Generated by the CPU 205 to generate a browser popup window that functions as the security window 120, and to generate a page transmitted from the security server 140 and display it on the popup security window 120. A web browser application 207 capable of The website page displayed by the browser 207 may hereinafter be referred to as a web page.
A security application 210 that can be executed by the CPU 205 to create the security window 120 and to generate and display the page transmitted from the security server 140 on the 2CHK security window 120. Hereinafter, it may be referred to as “2CHK client application”. The security application 210 may include a key management logic-client (KMLC) 213.
• Local storage including private stores 210a and 212a and public store 210b, which may be implemented in memory and / or hard drive data stores.
(1) A merchant or bank that can be executed by the CPU 205 to generate the website window 110 and generate and display the website page associated with the website 130 on the website window 110 Website application 212, such as an application. It should be understood that in practical implementations, there may be multiple different website applications, each associated with a different website accessible via the network.
A short message service (SMS) application 214 for sending text messages. Hereinafter, it may be referred to as “SMSA”.
An email application 216 for sending and receiving email over the network.
An Adobe Acrobat or Microsoft Word that can be executed by the CPU 205 to generate a document that is created on a computer device or sent to a computer device over a network and displayed in a window (not shown). Document processing application 218 such as It should be understood that in practical implementations, there may be multiple different document processing applications.
A proxy application that can be executed by the CPU 205 to create a secure pipeline for communication between the security application running on the auxiliary hardware and the security server 140; Hereinafter, it may be referred to as “2CHK proxy client application”.
A port 222 for communicatively connecting the computing device 100 to auxiliary hardware.

図3を参照すると、ユーザ・コンピュータ装置100との間で通信可能に相互接続されかつ切断されてもよい補助的ハードウェア300は、好ましくは下記のうちの幾つか、または全てを含む:
・ ディスプレイ画面302。
・ キーパッド、キーボード、マウスまたはユーザ入力の他の入力手段等の入力手段304。
・ 中央処理装置(CPU)305。
・ ディスプレイ画面302上にセキュリティウィンドウ120を作成し、かつ、セキュリティサーバ140から送信されるページを生成しかつセキュリティウィンドウ120に表示するためにCPU305によって実行されることが可能なセキュリティアプリケーション310。以後、「2CHKクライアントアプリケーション」と称される場合もある。セキュリティアプリケーション310は、API311および鍵管理ロジック−クライアント(KMLC)313を含んでもよい。
・ メモリおよび/またはハード・ドライブ・データ・ストアに実現されてもよい、プライベートストア312を含むローカルストレージ。
・ 補助的ハードウェア300が接続されるユーザ・コンピュータ装置100のポート222と補助的ハードウェア300との間で情報を送信するための、例えばUSBケーブル、近距離無線通信(NFC)、Bluetoothまたはヘッドフォンジャック、などを介して確立されるもの等の通信リンク320。
Referring to FIG. 3, auxiliary hardware 300 that may be communicatively interconnected and disconnected from user computing device 100 preferably includes some or all of the following:
Display screen 302.
• Input means 304 such as a keypad, keyboard, mouse or other input means for user input.
Central processing unit (CPU) 305.
A security application 310 that can be executed by the CPU 305 to create the security window 120 on the display screen 302 and to generate and display the page transmitted from the security server 140 on the security window 120. Hereinafter, it may be referred to as “2CHK client application”. The security application 310 may include an API 311 and a key management logic-client (KMLC) 313.
Local storage, including a private store 312 that may be implemented in a memory and / or hard drive data store.
For example, USB cable, near field communication (NFC), Bluetooth or headphones for transmitting information between the port 222 of the user computer device 100 to which the auxiliary hardware 300 is connected and the auxiliary hardware 300 A communication link 320, such as that established via a jack.

先に述べたように、セキュリティウィンドウ120は、コンピュータ装置100の画面105上において、ブラウザアプリケーション207により作成されるポップアップ・セキュリティ・ウィンドウに、またはセキュリティアプリケーション210、即ち2CHKクライアントによって作成される非ブラウザ・セキュリティ・ウィンドウに表示されてもよい。また、セキュリティウィンドウ120は、補助的ハードウェア300の画面302上において、セキュリティアプリケーション310、即ち2CHKクライアントによって作成される非ブラウザ・セキュリティ・ウィンドウにも表示されてもよい。セキュリティアプリケーション210は、様々な異なるフォームファクタのうちの何れによって実現されることも可能である。ある種類は、セキュリティウィンドウ120が、スマートフォンまたはスマートパッド等のモバイル・コンピュータ装置上のセキュリティアプリケーション210によって、例えば2CHKクライアントのスマートフォンアプリによって制御されることを企図している。別の種類は、セキュリティウィンドウ120が、デスクトップまたはラップトップコンピュータ等のより高性能のコンピュータ装置上のセキュリティアプリケーション210によって、例えば2CHKクライアントのパーソナルコンピュータ(PC)アプリケーションによって制御されることを企図している。さらに別の種類は、先に述べたように、セキュリティウィンドウ120が、通信機能を有するスマートカード等の専用または非専用補助的ハードウェア300上で実行されるセキュリティアプリケーション210によって制御されることを企図している。後にさらに論じるように、これらのフォームファクタは、単に、ブラウザを実行するユーザのPCとは独立していることによって、追加のセキュリティ層を提供する。スマートフォンは既に個人化され、かつ後述する技術によれば、OTPの生成はウェブサイト130およびセキュリティサーバ140のみが共有する秘密の使用に依存し、よってスマートフォンが特別な秘密を格納する、またはOTPソフトウェアを実行する必要はないことから、スマートフォン上での実現が容易に達成されることは認識されるであろう。むしろ、ウェブサイト130およびセキュリティサーバ140のみが、必要な秘密を共有すればよく、かつセキュリティサーバ140およびウェブサイト130のみが、ユーザのログイン認証およびトランザクション署名に要求されるOTPを生成すればよい。   As described above, the security window 120 is displayed on the screen 105 of the computer device 100 in a pop-up security window created by the browser application 207 or by the security application 210, ie, a non-browser client created by the 2CHK client. It may be displayed in the security window. The security window 120 may also be displayed on a non-browser security window created by the security application 310, ie, the 2CHK client, on the screen 302 of the auxiliary hardware 300. The security application 210 can be implemented by any of a variety of different form factors. One type contemplates that the security window 120 is controlled by a security application 210 on a mobile computing device such as a smartphone or smartpad, for example, by a 2CHK client smartphone app. Another type contemplates that the security window 120 is controlled by a security application 210 on a higher performance computing device, such as a desktop or laptop computer, for example, by a 2CHK client personal computer (PC) application. . Yet another type contemplates that the security window 120 is controlled by a security application 210 running on dedicated or non-dedicated auxiliary hardware 300, such as a smart card with communication capabilities, as described above. doing. As will be discussed further below, these form factors provide an additional layer of security simply by being independent of the user's PC running the browser. Smartphones are already personalized, and according to the technology described below, the generation of OTP relies on the use of secrets shared only by website 130 and security server 140, so that smartphones store special secrets, or OTP software It will be appreciated that realization on a smartphone is easily achieved since there is no need to execute. Rather, only the website 130 and the security server 140 need to share the necessary secrets, and only the security server 140 and the website 130 need generate the OTP required for user login authentication and transaction signature.

本発明の所定の態様によれば、セキュリティアプリケーションまたは2CHKクライアント210は、プライベートストア210aおよびパブリックストア210bの双方を用い、かつウェブサイトアプリケーション212も、パブリックストア210bのみならずプライベートストア212aを用いる。後により詳細に論じるように、CPU205は、通信チャネル142を介してセキュリティサーバ120と双方向通信するためにセキュリティアプリケーション210を実行することができ、かつ通信チャネル132を介してウェブサイト130と双方向通信しかつ通信チャネル142を介してセキュリティサーバ120と双方向通信するためにブラウザまたはウェブサイトアプリケーション212を実行することができる。   According to certain aspects of the invention, the security application or 2CHK client 210 uses both the private store 210a and the public store 210b, and the website application 212 uses the private store 212a as well as the public store 210b. As will be discussed in more detail later, the CPU 205 can execute a security application 210 to interact with the security server 120 via the communication channel 142 and interact with the website 130 via the communication channel 132. A browser or website application 212 may be executed to communicate and communicate with the security server 120 via the communication channel 142.

図3に示されているように、2CHKクライアント機能は、例えばUSBケーブル、近距離無線通信(NFC)、Bluetoothまたはヘッドフォンジャック、他を介してPCまたはスマートフォン等のコンピュータ装置へ、他の補助的なハードウェア製品に類似する方法で通信可能に取り付けられることが可能な専用または非専用補助的ハードウェア300上で利用可能にされてもよい。補助的ハードウェアは、例えばスマートカード、安全な記憶装置、安全なディスプレイ装置、または証明書ストアまたは生体情報読取装置または指紋保護型記憶装置、他等の補助的識別情報の安全なソースを含む、任意のタイプであり得る。また、補助的ハードウェアは、PCへ通信可能に取り付けることができるスマートフォンであり得ること、かつデスクトップ、ラップトップまたはスマート・モバイル・デバイスの代わりに、ゲーム装置、TV、DVDプレーヤ、他等の任意のインターネット接続デバイスがコンピュータ装置100の代用にされることが可能でありかつ補助的ハードウェアのプロキシまたはコンジットとして機能する中間点となり得ることも理解されるべきである。補助的ハードウェア上に2CHKクライアント機能を保有すれば、結果的に、コンピュータ装置100自体に対する攻撃を防護するための安全性をさらに高めることができる。   As shown in FIG. 3, the 2CHK client function can be connected to a computer device such as a PC or a smartphone via a USB cable, near field communication (NFC), Bluetooth or headphone jack, etc. It may be made available on dedicated or non-dedicated auxiliary hardware 300 that can be communicatively attached in a manner similar to a hardware product. Auxiliary hardware includes a secure source of auxiliary identification information such as, for example, a smart card, secure storage device, secure display device, or certificate store or biometric reader or fingerprint protected storage device, etc. It can be of any type. Also, the auxiliary hardware can be a smartphone that can be communicatively attached to a PC, and can be any game device, TV, DVD player, etc. instead of a desktop, laptop or smart mobile device It should also be understood that other Internet connection devices can be substituted for the computer device 100 and can be a midpoint that functions as a proxy or conduit for auxiliary hardware. If the 2CHK client function is provided on the auxiliary hardware, as a result, it is possible to further increase the safety for protecting against attacks on the computer apparatus 100 itself.

2CHKクライアント機能が補助的ハードウェア上に存在することにより、コンピュータ装置100は(デスクトップまたはラップトップコンピュータであれ、スマートフォンまたはスマートパッドであれ)、基本的に、セキュリティサーバ140とコンピュータ装置100へ取り付けられる補助的ハードウェアとの間でメッセージを運ぶためのコンジット(または、プロキシ)として行動している。即ち、コンピュータ装置100上で実行されるセキュリティアプリケーション、即ち2CHKクライアント210によって果たされる役割は、今度は代わりに、補助的デバイス上で実行されるセキュリティアプリケーション、即ち2CHKクライアント310によって果たされる。   Due to the presence of the 2CHK client function on the auxiliary hardware, the computing device 100 (whether a desktop or laptop computer, a smartphone or a smartpad) is basically attached to the security server 140 and the computing device 100. Acting as a conduit (or proxy) to carry messages to and from auxiliary hardware. That is, the role played by the security application running on the computer device 100, i.e. the 2CHK client 210, is now played instead by the security application running on the auxiliary device, i.e. the 2CHK client 310.

補助的ハードウェア300は、コンピュータ装置100へポート222および通信リンク320を介して着脱可能式に接続される。セキュリティアプリケーション、即ち2CHKクライアント310は、CPU315およびユーザによってプライベートストア312およびパブリックストア210bの双方で実行可能である。セキュリティアプリケーション、即ち2CHKクライアント310は、セキュリティサーバ140と、安全な通信チャネル144、プロキシ220、ポート222および通信リンク320を介して双方向通信する。プロキシ/コンジットアプリケーション220は、通信リンク320、ポート222および通信チャネル144と共にセキュリティサーバ140とセキュリティアプリケーション210との間の安全な通信パイプラインとして機能するようにCPU205によって実行される。またこれは、通信リンク320およびポート222と共に、セキュリティアプリケーション310とコンピュータ装置100上のパブリックストレージ210bとの間の通信パイプラインとしても機能する。したがって、セキュリティサーバ140とセキュリティウィンドウ120との間の通信が、「コンジット/プロキシ」として機能するコンピュータ装置100によって読み取られる、または操作されることはない。言い替えれば、コンピュータ装置100を介して補助的ハードウェアへ送られるデータは、補助的ハードウェア上で実行されるセキュリティアプリケーション、即ち2CHKクライアント310にしか読み取れないようにして暗号化または符号化される。
2CHKシステムの動作
The auxiliary hardware 300 is detachably connected to the computer device 100 via the port 222 and the communication link 320. The security application, ie 2CHK client 310, can be executed by both CPU 315 and the user in both private store 312 and public store 210b. The security application, or 2CHK client 310, communicates with the security server 140 through a secure communication channel 144, a proxy 220, a port 222 and a communication link 320. Proxy / conduit application 220 is executed by CPU 205 to function as a secure communication pipeline between security server 140 and security application 210 along with communication link 320, port 222 and communication channel 144. It also serves as a communication pipeline between the security application 310 and the public storage 210b on the computer device 100, along with the communication link 320 and port 222. Accordingly, communications between the security server 140 and the security window 120 are not read or manipulated by the computing device 100 functioning as a “conduit / proxy”. In other words, the data sent to the auxiliary hardware via the computer device 100 is encrypted or encoded so that it can only be read by the security application running on the auxiliary hardware, ie the 2CHK client 310.
Operation of 2CHK system

動作には、次のような明確な5段階が存在する:(i)セキュリティウィンドウ120のセットアップおよび個性化、これは、1回限りの処理である、(ii)ポップアップ・セキュリティ・ウィンドウであれ、2CHKセキュリティウィンドウであれ、セキュリティウィンドウ120の始動または起動、これは、使用毎のコンピュータへのログインと同様に、定期的に発生する、(iii)ユーザが、セキュリティサーバ140を介してユーザに対して自らを認証するウェブサイト130を閲覧する場合の、ユーザに対するウェブサイト130の認証、(iv)ユーザがウェブサイト130を閲覧する、またはウェブサイトアプリケーション212を起動する場合の、例えばログインを目的とする、セキュリティサーバ140によるユーザのウェブサイト130またはウェブサイトアプリケーション212に対する認証、および(v)ユーザがウェブサイト130を閲覧するか又は、ウェブサイトアプリケーション212を用い、かつウェブサイト130との特定のトランザクションの開始を希望する場合の、トランザクションの承認またはトランザクション署名。
セットアップおよび個性化段階
There are five distinct phases of operation: (i) security window 120 setup and personalization, which is a one-time process, (ii) pop-up security window, The startup or activation of the security window 120, whether it is a 2CHK security window, which occurs periodically, as well as logging in to the computer on every use, (iii) The user is directed to the user via the security server 140 Authentication of the website 130 for the user when browsing the website 130 for authenticating itself, (iv) For the purpose of login, for example, when the user browses the website 130 or starts the website application 212 , User by security server 140 Authentication to website 130 or website application 212, and (v) if the user views website 130 or uses website application 212 and wishes to initiate a specific transaction with website 130. Transaction approval or transaction signature.
Setup and personalization phase

ユーザは、その2CHKシステムとの関連付けを、1回限りの処理であるセットアップおよび個性化段階を介して開始する。セットアップするために、ユーザは、セキュリティサーバ140においてホストされるネットワークサイトを訪れる。セキュリティアプリケーション、即ち2CHKクライアント210または310が実現に利用されるのであれば、適用可能なセキュリティアプリケーションは、ユーザのコンピュータ装置100へアップロードされ、かつコンピュータ装置100上または補助的ハードウェア300上へ、典型的には、適用可能なデバイス100または300上で利用可能な、例えばメモリ、ハードドライブまたは他のローカル・ストレージ・オプションであるローカルストレージ上へ、格納される。実現の仕方によっては、セキュリティアプリケーション210およびセキュリティアプリケーション310の双方が利用され、よってセットアップ処理中に双方がアップロードされる必要があることは理解されるべきである。ユーザは、個性化画像を選択する。この画像は、ユーザのコンピュータ装置100上へクッキーを用いて局所的に格納される。これは、一般に、ユーザ毎、ユーザ・コンピュータ装置100毎の1回限りの事象であって、ユーザが個性化画像の変更を希望する、またはローカルストレージが何らかの理由で削除される場合にのみ反復されることを要する。
始動および起動(セキュリティ・サーバ・ログイン)段階
The user initiates its association with the 2CHK system through a one-time process, setup and personalization phase. To set up, the user visits a network site hosted on the security server 140. If a security application, ie, 2CHK client 210 or 310, is utilized for implementation, the applicable security application is uploaded to the user's computer device 100 and is typically on the computer device 100 or auxiliary hardware 300. Specifically, it is stored on local storage available on the applicable device 100 or 300, for example memory, hard drive or other local storage options. It should be understood that depending on the implementation, both security application 210 and security application 310 are utilized, and thus both need to be uploaded during the setup process. The user selects a personalized image. This image is stored locally on the user's computer device 100 using cookies. This is typically a one-time event per user, per user computer device 100, and is repeated only if the user wants to change the personalized image or the local storage is deleted for some reason. It is necessary to.
Startup and startup (security server login) phase

起動は、典型的には周期的に発生し、例えば日に一度、ユーザがウェブの閲覧を開始する前に発生する。実現形態に依存して、ユーザは、起動処理を手動で開始することができ、あるいは、起動処理は、ユーザが2CHKシステムに参加するウェブサイト130を訪れた際に自動的に開始されても良い。この後、セキュリティサーバ140は、OOBAサーバ150を介するOOBAを通じたユーザの検証に基づいてセキュリティウィンドウ120を起動する。しかしながら、この段階では、望ましい場合には、OOBAでない他の形式の検証が使用されることも可能であることは理解されるべきである。他の形式の検証が、2CHKシステムと既存のOTP配備との統合をより容易にする場合があることは認識されるであろう。   Activation typically occurs periodically, for example, once a day, before the user starts browsing the web. Depending on the implementation, the user can manually initiate the activation process, or the activation process may be initiated automatically when the user visits the website 130 participating in the 2CHK system. . Thereafter, the security server 140 activates the security window 120 based on user verification through OOBA via the OOBA server 150. However, it should be understood that at this stage, other forms of verification that are not OOBA may be used if desired. It will be appreciated that other forms of verification may facilitate the integration of 2CHK systems with existing OTP deployments.

一般に始動のための「開放」モデルOOBAと称されるものを用いて、起動は、好ましくは、ユーザにより次のようにしてもたらされる。セキュリティサーバ140に対するユーザの検証に際しては、(1)ユーザが、その電話番号、例えば有線電話、携帯電話またはスマート携帯電話の電話番号を、例えばデスクトップコンピュータまたはスマートフォンであるユーザ・コンピュータ装置100または補助的ハードウェア300上で実行されるセキュリティアプリケーション、即ち2CHKクライアント210または310またはブラウザアプリケーション207(セキュリティウィンドウがブラウザのポップアップ・セキュリティ・ウィンドウであれば)により表示されるセキュリティウィンドウ120へ入力するか、または(2)セキュリティアプリケーション210または310またはブラウザ207が、ユーザのコンピュータ装置100から直接番号を入手する。入力された、または他の方法で入手された電話番号は、コンピュータ装置100から通信チャネル144を介してセキュリティサーバ140へ、または、補助的ハードウェア300から通信リンク320およびチャネル144を介してセキュリティサーバ140へ送信される。   Using what is commonly referred to as an “open” model OOBA for start-up, activation is preferably effected by the user as follows. When verifying a user with respect to the security server 140, (1) the user uses his / her telephone number, for example, a telephone number of a wired telephone, a mobile phone or a smart mobile phone, for example, a user computer device 100 which is a desktop computer or a smart phone, or an auxiliary Input to the security window 120 displayed by the security application running on the hardware 300, ie, the 2CHK client 210 or 310 or browser application 207 (if the security window is a browser pop-up security window), or ( 2) The security application 210 or 310 or the browser 207 obtains the number directly from the user's computer device 100. The telephone number entered or otherwise obtained is sent from the computing device 100 to the security server 140 via the communication channel 144 or from the auxiliary hardware 300 via the communication link 320 and the channel 144. 140.

セキュリティサーバ140は、ログインのセキュリティコードを、通信チャネル146を介してOOBAサーバ150へ伝達する。OOBAサーバ150は、セキュリティサーバ140に対してユーザを認証するために、ユーザにログインのセキュリティコードを提供すべく通信チャネル152を介してユーザの携帯電話、スマートパッドまたはスマートフォン160と通信する。OOBAサーバ150がユーザへ起動コードを伝達する手段には、テキストメッセージ、音声呼、eメール、または、セキュリティアプリケーション210または310またはブラウザ207がセキュリティサーバ140と通信する手段であるチャネルとは実質的に異なり、よって双方のチャネルへの不正侵入が実質的により困難になる、他の任意の通信チャネルが含まれることが可能であるが、これに限定されない。   The security server 140 transmits the login security code to the OOBA server 150 via the communication channel 146. The OOBA server 150 communicates with the user's mobile phone, smart pad, or smartphone 160 via the communication channel 152 to provide the user with a login security code to authenticate the user to the security server 140. The means by which the OOBA server 150 communicates the activation code to the user is substantially a text message, voice call, email, or channel that is the means by which the security application 210 or 310 or browser 207 communicates with the security server 140. It can include, but is not limited to, any other communication channel that is different and thus makes intrusion into both channels substantially more difficult.

通信チャネル152が、典型的にはその可能性が最も高いと思われる双方向性であれば、通信チャネル152は、場合により、OOBAサーバ150によりアクセス可能で、共有秘密、居場所情報および生体情報識別子を含むが、これらに限定されない識別情報と比較するために、追加の認証情報を捕捉することにより、ユーザと双方向通信して起動コードの配信より前にユーザをより完全に認証するように利用されることが可能である。   If the communication channel 152 is typically bi-directional, which is likely to be the most likely, the communication channel 152 is optionally accessible by the OOBA server 150 and is shared secret, location information and biometric identifier. To capture additional authentication information for comparison with, but not limited to, identification information, including two-way communication with the user to more fully authenticate the user prior to delivery of the activation code Can be done.

セキュリティコードの鍵付きハッシュは、暗号化された通信チャネル144および妥当であればリンク320を介してセキュリティサーバ140へ送られる。セキュリティサーバ140に対するユーザのこのような検証は、当然ながら、セキュリティサーバ140がセキュリティウィンドウ120を介してユーザへ、例えばウェブサイトへのログインを目的として、またはウェブサイト130とのトランザクションを承認するために、ウェブサイト130に対する認証用に要求される認証情報を提供する前に実行される。   The keyed hash of the security code is sent to the security server 140 via the encrypted communication channel 144 and link 320 if appropriate. Such verification of the user against the security server 140 is, of course, for the security server 140 to login to the user via the security window 120, eg, for the purpose of logging into the website, or for authorizing a transaction with the website 130. This is executed before providing authentication information required for authentication to the website 130.

一方で、一般に「関連付け」OOBAモデルと称されるものが始動に利用されれば、起動は、好ましくは、ユーザではなく企業、例えばウェブサイト130によってもたらされる。したがって、ユーザは、関連付けOOBAモデルにおけるセキュリティアプリケーション、即ち2CHKクライアント210または310へ電話番号を入力する必要はなく、よって入力しない。代わりに、ユーザは、ブラウザアプリケーション207により伝達されるウェブサイト130の安全機構、またはユーザ識別子とパスワードとの組合せ等のウェブサイトアプリケーション212の安全機構を用いて企業へ、例えばウェブサイト130へログインする。ユーザは、2CHK関連付けを、ウェブサイトウィンドウ110におけるユーザのブラウザアプリケーション207またはウェブサイトアプリケーション212により提示されるウェブサイト130のウェブページから選択することによって要求する。   On the other hand, if what is commonly referred to as an “association” OOBA model is utilized for start-up, the start-up is preferably effected by the company, eg, website 130, rather than the user. Thus, the user need not enter a telephone number into the security application in the association OOBA model, ie, the 2CHK client 210 or 310, and thus does not. Instead, the user logs into the company, eg, the website 130 using the website 130 safety mechanism communicated by the browser application 207 or the website application 212 safety mechanism, such as a combination of a user identifier and password. . The user requests a 2CHK association by selecting from the web page of the website 130 presented by the user's browser application 207 or website application 212 in the website window 110.

例えば、ユーザは、マスクされたアドレスまたは電話番号、即ちウェブサイト130が事前に入手可能なものであってユーザには完全に示されないアドレスまたは電話番号、例えば415.680.xxxx等である連絡先情報を含む識別情報を選択することによって、2CHK関連付けを要求するように求められる場合もある。このような場合、ウェブサイト130は、例えば有線電話または携帯電話の番号である電話番号を有する関連付け要求を、ユーザの認証および起動においてセキュリティサーバ140により使用されるためにセキュリティサーバ140へ送る。望ましい場合には、連絡先情報は、電話呼によってユーザに連絡するための情報の代わりに、ユーザにより選択される、好ましくはマスクされた適用可能な識別情報を有する、手渡し、NFC/Bluetooth交換または知識ベースの認証(KBA)照会、他によってユーザに連絡するための情報であることも可能であることは留意されるべきである。あるいは、ユーザは、2CHK関連付けを、単に2CHK起動ボックスをクリックするだけで要求するように求められる場合もある。このような場合、ウェブサイト130は、所望されれば、ユーザの認証および起動においてセキュリティサーバにより使用されるための企業起動コードを生成し、かつこれをセキュリティサーバ140へ送ることができる。   For example, the user may have a masked address or phone number, i.e., an address or phone number that the website 130 is pre-available and not fully shown to the user, e.g., 415.680. It may be required to request 2CHK association by selecting identification information including contact information such as xxx. In such a case, the website 130 sends an association request having a phone number, for example a wired phone or mobile phone number, to the security server 140 for use by the security server 140 in user authentication and activation. If desired, the contact information may be handed over, NFC / Bluetooth exchange or preferably with masked applicable identification information selected by the user, instead of information for contacting the user by telephone call. It should be noted that the information can also be information to contact the user via a knowledge-based authentication (KBA) query, etc. Alternatively, the user may be asked to request a 2CHK association simply by clicking on the 2CHK activation box. In such a case, the website 130 can generate and send an enterprise activation code to the security server 140 for use by the security server in user authentication and activation, if desired.

ウェブサイト130またはウェブサイトアプリケーション212は、関連付け要求を、好ましくは選択された完全な連絡先情報、例えば選択された完全な電話番号、例えば415.680.0000、またはユーザ識別情報(ユーザによって選択されたものではない)を含む識別情報および企業起動コードと共に、適宜、ウェブサイトウィンドウ110とセキュリティサーバ140との間の通信チャネル132および142を介して、またはウェブサイト130とセキュリティサーバ140との間の直接的な安全な通信チャネル134を介してセキュリティサーバ140へ送信する。   The website 130 or website application 212 may request the association request, preferably the complete contact information selected, eg the complete phone number selected, eg 415.6680.0000, or the user identification information (selected by the user). As well as the identification information and company activation code, including the communication channel 132 and 142 between the website window 110 and the security server 140, or between the website 130 and the security server 140, as appropriate. Transmit to the security server 140 via a direct secure communication channel 134.

この時点から、セキュリティサーバ140は、OOBA比較用に利用可能な識別情報および恐らくはOOBA比較の起動コードがこれでセキュリティサーバおよび企業の双方から到来することを除いて、「開放」モデルと全く同様に進行する。識別情報または識別コードは、好ましくは妥当な企業への妥当な要求に固有のものであり、同時的に、エンドユーザへ例えば公衆交換電話網(PSTN)を介して配信されかつセキュリティサーバ140内に格納される。セキュリティサーバ140は、セキュリティアプリケーション、即ち2CHKクライアント210または310によるセキュリティサーバ起動コードおよび妥当であれば企業起動コードの配信を待機し、かつこれらのコードを受信した時点で、セキュリティアプリケーション、即ち2CHKクライアント210又は310を、例えばウェブサイト130である企業からの特定の要求へ結び付ける。即ち、セキュリティコードの鍵付きハッシュは、暗号化された通信チャネル144および妥当であればリンク320を介してセキュリティサーバ140へ送られる。受信されたコードに基づいてセキュリティサーバによりユーザが検証されれば、セキュリティサーバ140とセキュリティアプリケーション、即ち2CHKクライアント210または310との間のさらなる通信は、通信チャネル144および妥当であれば通信リンク320が安全であるように、起動コードを用いて暗号化される。ここで、当然ながら、このようなセキュリティサーバ140に対するユーザの検証は、ユーザがウェブサイト130に対する認証に要求される認証情報を例えばウェブサイトへのログインを目的として提供した後に、但し、セキュリティサーバ140がユーザにセキュリティウィンドウ120を介して、安全な通信チャネル144および妥当であれば通信リンク320上で送信される認証情報であって、ウェブサイト130とのトランザクションを承認するために要求される認証情報を提供する前に実行される。   From this point on, the security server 140 is identical to the “open” model, except that the identification information available for OOBA comparison and possibly the OOBA comparison activation code now comes from both the security server and the enterprise. proceed. The identification information or identification code is preferably unique to a valid request to a valid company and is simultaneously distributed to the end user, for example via the public switched telephone network (PSTN) and within the security server 140. Stored. The security server 140 waits for delivery of the security application, i.e., the security server activation code by the 2CHK client 210 or 310 and, if appropriate, the enterprise activation code, and upon receiving these codes, the security application, i.e., the 2CHK client 210. Or 310, for example, to a specific request from a company that is a website 130. That is, the keyed hash of the security code is sent to the security server 140 via the encrypted communication channel 144 and link 320 if appropriate. If the user is verified by the security server based on the received code, further communication between the security server 140 and the security application, i.e., the 2CHK client 210 or 310, is communicated to the communication channel 144 and, if appropriate, the communication link 320. To be secure, it is encrypted using an activation code. Here, as a matter of course, verification of the user with respect to the security server 140 is performed after the user provides authentication information required for authentication with respect to the website 130 for the purpose of logging in to the website, for example. Authentication information sent to the user via the security window 120 over the secure communication channel 144 and, if appropriate, over the communication link 320, the authentication information required to authorize the transaction with the website 130. Executed before offering.

2CHKシステムを用いたユーザと企業との間の関連付けの重要性は、特定の企業の特定のアカウント/関係性へ結び付けることにある。したがって、ここでは、企業が処理を制御して、セキュリティアプリケーション、即ち2CHKクライアント210または310が特定のアカウントに関連づけられることを許し、又は可能にする。   The importance of the association between users and companies using the 2CHK system is to link to specific accounts / relationships of specific companies. Thus, here the enterprise controls the process to allow or allow the security application, ie 2CHK client 210 or 310, to be associated with a particular account.

OOBAを介してユーザが検証されると、セキュリティウィンドウ120が起動されて、ユーザのコンピュータ装置100または補助的ハードウェア300上の比較的小さいスペースを占有する。セキュリティウィンドウ120を始動する行為は、セキュリティサーバ140がユーザのコンピュータ装置100または補助的ハードウェア300上へローカル・セッション・オブジェクト、例えばセッションクッキーを仕掛ける結果ももたらす。この時点で、セキュリティサーバ140は、セキュリティサーバ140が何らかのユーザ識別子、例えばOOBAに使用される電話番号によって識別するユーザに開放された、機能中の安全な通信チャネル144を有する。   When a user is verified via OOBA, a security window 120 is activated to occupy a relatively small space on the user's computing device 100 or auxiliary hardware 300. The act of starting the security window 120 also results in the security server 140 placing a local session object, such as a session cookie, on the user's computing device 100 or auxiliary hardware 300. At this point, the security server 140 has a functioning secure communication channel 144 open to the user that the security server 140 identifies by some user identifier, eg, a telephone number used for OOBA.

通信チャネル144上で送信される情報の暗号化には、2つのレベルが存在する。第1に、全てのトラフィックがSSL上で実行される。第2に、全てのトラフィックは、アプリケーションレベルにおいても、セキュリティサーバ140へログインするためにユーザにより使用されるセキュリティから導出される鍵を用いて暗号化される。セキュリティウィンドウ120およびセキュリティサーバ140はSSL上で通信していることから、EV−SSL証書の使用が極めて好ましいことは留意されるべきである。SSLおよびEV−SSL証書は共に、当業者には周知でありかつ理解されている。   There are two levels of encryption of information transmitted over the communication channel 144. First, all traffic is executed over SSL. Second, all traffic is also encrypted at the application level with a key derived from the security used by the user to log into the security server 140. It should be noted that the use of EV-SSL certificates is highly preferred since security window 120 and security server 140 are communicating over SSL. Both SSL and EV-SSL certificates are well known and understood by those skilled in the art.

コンピュータ装置100または補助的ハードウェア300がスマートフォンまたは他のスマートモバイル通信デバイスである場合、所定の動作は、望ましい場合には、スマートフォンの所定の一般的な機能および性能を利用するように実現されてもよい。   If the computing device 100 or auxiliary hardware 300 is a smartphone or other smart mobile communication device, certain operations are implemented to utilize certain general functions and capabilities of the smartphone, if desired. Also good.

例えば、OOBAサーバ150にとっては、セキュリティコードをユーザへテキストメッセージで伝達することが有益である場合がある。このような場合、ユーザは、SMSA214を介してログインのセキュリティコードを有するテキストメッセージを受信した後、セキュリティサーバ140へログインするために、即ちセキュリティサーバ140に対して検証するために、受信されたログインのセキュリティコードを、スマートフォン100上で実行されるセキュリティアプリケーション、即ち2CHKクライアント210によって、またはスマートフォン100へ接続される補助的ハードウェア300上で実行されるセキュリティアプリケーション、即ち2CHKクライアント310によって提示されるセキュリティウィンドウ120へ入力することができる。幾つかのスマートフォンプラットフォーム上において、セキュリティアプリケーション210は、望ましい場合には、着信するテキスト・メッセージ・ストリームからログインのセキュリティコードを検索し、かつまたログインのセキュリティコードをセキュリティウィンドウ120へ自動記入するように構成されることが可能であって、ユーザに対する利便性がさらに高められる。   For example, it may be beneficial for OOBA server 150 to communicate the security code to the user in a text message. In such a case, after the user receives a text message with a login security code via SMSA 214, the user receives the login received to log in to security server 140, ie to verify against security server 140. Security code executed by the security application executed on the smartphone 100, that is, the 2CHK client 210, or the security application executed on the auxiliary hardware 300 connected to the smartphone 100, that is, the security provided by the 2CHK client 310. Input to window 120 is possible. On some smartphone platforms, the security application 210 retrieves the login security code from the incoming text message stream, if desired, and also automatically fills the security window 120 with the login security code. It can be configured and the convenience for the user is further enhanced.

何れにしても、セキュリティサーバ140からセキュリティアプリケーション、即ち2CHKクライアント210または310への返信メッセージは、転送されたセキュリティコードが有効であれば、セッションクッキー、「ノンスログイン」と呼ばれる乱数および有効期間(TTL)である。セッションクッキーは、非公開で、適宜プライベートストア210aまたは312に格納される。ノンスログインおよびTTLは、カスタムペーストボード、セキュリティアプリケーション、またはパブリックストア210b内に生成される2CHKクライアントのパブリックペーストボード上に公開して格納される。ユーザがその焦点をセキュリティアプリケーション、即ち2CHKクライアント210または310へ向けると、セキュリティアプリケーション210は、TTLが時間切れになっていないことを保証するために、常にノンスおよびTTLをチェックする。   In any case, the reply message from the security server 140 to the security application, that is, the 2CHK client 210 or 310, if the transferred security code is valid, a session cookie, a random number called “nonce login” and a valid period (TTL) ). The session cookie is private and stored in the private store 210a or 312 as appropriate. The nonce login and TTL are publicly stored on a custom pasteboard, security application, or 2CHK client public pasteboard generated in the public store 210b. When the user focuses their focus on a security application, ie 2CHK client 210 or 310, security application 210 always checks the nonce and TTL to ensure that the TTL has not expired.

ユーザが一旦セキュリティサーバ140へログインすると、ユーザは次に、ウェブサイトアプリケーション212またはブラウザアプリケーション207等の他のアプリケーションの使用を開始し、かつ必要に応じてセキュリティアプリケーション、即ち2CHKクライアント210へ戻ってもよい。   Once the user has logged in to the security server 140, the user can then begin using other applications such as the website application 212 or browser application 207, and return to the security application, i.e. the 2CHK client 210, if necessary. Good.

先に述べたように、ユーザは、この2ステップ起動を、例えば(i)ユーザの電話番号または携帯電話番号を、適宜ユーザのコンピュータ装置100または補助的ハードウェア300上で実行されるセキュリティアプリケーション210または310によって提示されるセキュリティウィンドウ120へ入力し、かつ(ii)入力された番号においてOOBAサーバ150から起動コードを音声またはテキストメッセージによって受信し、かつ受信された起動コードを、セキュリティサーバ140へ転送して返すためにセキュリティウィンドウ120へ入力すること、によって完了する。ステップ(ii)は、ステップ(i)に続いて直ちに発生し、この後、ユーザは、2CHKシステムを介してトランザクションを受信できる状態になる。   As described above, the user performs this two-step activation, for example, (i) a security application 210 that is executed on the user's computer device 100 or auxiliary hardware 300 as appropriate, for example, (i) the user's phone number or mobile phone number. Or (ii) receiving an activation code by voice or text message from the OOBA server 150 at the entered number and transferring the received activation code to the security server 140. Complete by entering into the security window 120 to return. Step (ii) occurs immediately following step (i), after which the user is ready to receive transactions via the 2CHK system.

しかしながら、OOBAサーバ150は、セキュリティサーバ140から受信する起動コードを(音声またはテキストメッセージを介して)電話番号宛に、その番号について何ら知識もないまま送信していることから、潜在的問題が発生する可能性もある。これにより、システムがなりすまし攻撃を受けやすくなるものではないが、システムが、例えば攻撃者が地元のピザ配送所の番号を入力し、ユーザが続いて、例えば地元のピザ配送所であるウェブサイトにより転送された例えばピザの注文であるトランザクションを承認せずに拒絶する、という迷惑攻撃を受けやすくなる可能性はある。即ち、開放モデルでは、攻撃者がセキュリティアプリケーション、即ち2CHKクライアント210または310へユーザの電話番号を入力して起動を開始させる可能性もある。これは、技術的に言えば攻撃ではないが、ユーザは結果的に、OOBAサーバから迷惑コールまたはテキストを受信する。   However, because the OOBA server 150 sends the activation code received from the security server 140 to the telephone number (via voice or text message) without any knowledge about the number, a potential problem has occurred. There is also a possibility to do. This does not make the system susceptible to spoofing attacks, but the system can be used, for example, by an attacker entering a local pizza delivery number, followed by a user, for example, a website that is a local pizza delivery location. There is a possibility of being susceptible to a nuisance attack of rejecting a transferred transaction such as a pizza order without approving it. That is, in the open model, an attacker may enter the user's telephone number into the security application, that is, the 2CHK client 210 or 310 to start activation. This is technically not an attack, but the user eventually receives an unwanted call or text from the OOBA server.

この潜在的な問題点は、上述の起動処理を起動ステップが時差式に実行されるように修正することにより、改善されることが可能である。より具体的には、ユーザは、時差式の起動を用いて電話番号を通常の方法で適宜、ユーザのコンピュータ装置100または補助的ハードウェア300上で実行されるセキュリティアプリケーション210または310により提示されるセキュリティウィンドウ120へ入力する。しかしながら、入力された番号においてOOBAサーバ150から起動コードを直ちに受信するのではなく、ユーザは、入力された番号において、ユーザが「擬似的に起動されている」こと、およびこの起動は後に完成されることを通知される。後に、例えばウェブサイト130である企業が電話番号により識別されるユーザへのトランザクションの送信を希望する時点で、例えばウェブサイト130である企業は、トランザクション、およびユーザを識別する電話番号をセキュリティサーバ140へ送る。セキュリティサーバ140が「擬似的に起動されている」状態にあるその電話番号(と装置との組合せ)を有していれば、セキュリティサーバ140は、まず、OOBAサーバ150へ起動コードを送ってユーザの起動を正常に完了させる。起動の完了後、セキュリティサーバ140は、通信チャネル144を介してユーザのコンピュータ装置100上のセキュリティウィンドウ120へトランザクションを送る。ユーザは、この時点で完全に起動されていて、起動の完了を要求しないことから、この後、後続のトランザクションは通常の方式で処理される。
ウェブサイト認証段階
This potential problem can be remedied by modifying the activation process described above so that the activation step is executed in a time difference manner. More specifically, the user is presented with a security application 210 or 310 running on the user's computing device 100 or ancillary hardware 300, as appropriate, in a normal manner, using time difference activation. Input to the security window 120. However, instead of immediately receiving the activation code from the OOBA server 150 at the entered number, the user is “simulated activated” at the entered number and this activation is later completed. To be notified. Later, for example, when a company, such as website 130, wishes to send a transaction to a user identified by a telephone number, the company, such as website 130, may enter the transaction and the telephone number identifying the user into security server 140. Send to. If the security server 140 has the telephone number (and the combination of the devices) in the “pseudo-activated” state, the security server 140 first sends an activation code to the OOBA server 150 to the user. To complete the startup successfully. After activation is complete, the security server 140 sends a transaction to the security window 120 on the user's computing device 100 via the communication channel 144. Since the user is fully activated at this point and does not request completion of activation, subsequent transactions are then processed in the normal manner.
Website authentication stage

2CHKシステムに参加するウェブサイト130は、ブラウザ207により閲覧されるウェブページまたはウェブサイトアプリケーション212により提示されるウェブサイトページに、2CHKシステムにアクセスするためのコードを埋め込む。典型的には、これは、iFrame内部のJavascriptコードの形式となる。コードは、セキュリティサーバ140へ先に仕掛けられたローカル・セッション・オブジェクトを転送する行為の要求に従って、セキュリティサーバ140へ届く。   The website 130 participating in the 2CHK system embeds a code for accessing the 2CHK system in a web page viewed by the browser 207 or a website page presented by the website application 212. Typically, this will be in the form of JavaScript code inside iFrame. The code arrives at the security server 140 in accordance with a request for the act of transferring a previously initiated local session object to the security server 140.

セキュリティサーバ140は、iFrameからの要求のReferrerまたはOriginタグを、許可/禁止サイトの既知のホワイトリストおよび/またはブラックリストに照らしてチェックする。これは、次に、iFrameに応答し、かつ同時に自らが通信状態にあるセキュリティウィンドウ120に信号で伝える。信号は、2つの部分からなり、第1の部分は、ウェブサイト130が「良い」か「悪い」か、またはセキュリティサーバ140はウェブサイト130を「知らない」ことを示す。信号の第2の部分は、(ウェブサイト130が正規のものであれば)セキュリティウィンドウ120およびiFrameへ送られるランダム画像である。ウェブサイト130が正規であれば、ユーザのセキュリティウィンドウ120は、ウェブサイト130が「良い」ものであるという視覚的合図(例えば、緑色の光)を有し、かつランダム画像を示す。iFrameも、同様の視覚的合図を示し、かつ極めて重要な点として、同じランダム画像も示す。ウェブサイト130がブラックリストに存在していれば、セキュリティウィンドウ120は、ウェブサイト130が「悪い」ものであることを示す視覚的合図(例えば、赤色光)を示す。   The security server 140 checks the Referer or Origin tag of the request from the iFrame against the known whitelist and / or blacklist of allowed / forbidden sites. This in turn signals the security window 120 in response to the iFrame and at the same time it is in communication. The signal consists of two parts, the first part indicating that the website 130 is “good” or “bad” or that the security server 140 “does not know” the website 130. The second part of the signal is a random image sent to security window 120 and iFrame (if website 130 is legitimate). If the website 130 is legitimate, the user's security window 120 has a visual cue (eg, green light) that the website 130 is “good” and shows a random image. iFrame also shows a similar visual cue and, as a very important point, shows the same random image. If the website 130 is on the black list, the security window 120 shows a visual cue (eg, red light) indicating that the website 130 is “bad”.

偽のセキュリティウィンドウを生成することによって2CHKシステムを破ろうとする攻撃者は、個性化画像を知り得ないことに起因して阻まれる。また、iFrameに視覚的合図を表示しようとする攻撃者は、セキュリティウィンドウ120へ送られるランダム画像を知らないことに起因して成功しない。最後に、偽のウェブサイトは、ブラウザによって点検されることから、ReferrerまたはOriginタグを操作することができない。
ユーザ認証(例えば、ウェブサイトへのログイン)段階
Attackers who try to break the 2CHK system by generating a fake security window are blocked because they do not know the personalized image. Also, an attacker trying to display a visual cue on iFrame will not succeed due to not knowing the random image sent to the security window 120. Finally, fake websites are inspected by the browser, so they cannot manipulate Referer or Origin tags.
User authentication (eg, login to website) phase

好ましくは、始動の間、ユーザはセキュリティサーバ140に対し、セキュリティサーバ140の要求で電話番号を所有していることを証明するためにOOBAサーバ150により実行されるOOBA技術を用いて認証される。これが発生した後、セキュリティサーバ140は、ウェブサイト130からのユーザ識別アサーション要求に応えることができる。これを実行するために、セキュリティサーバ140、および2CHKシステム内の個々のウェブサイト130は、2CHKシステムに参加していてこのウェブサイトを訪れる全てのユーザに関して、異なる共有秘密について事前に合意している。即ち、セキュリティサーバおよび各ウェブサイト130は、いかなるユーザにも他のウェブサイトにも知られておらず、かついかなる特定のユーザにも関連付けられていない共有秘密を有する。   Preferably, during startup, the user is authenticated to security server 140 using OOBA technology executed by OOBA server 150 to prove possession of the telephone number at the request of security server 140. After this occurs, the security server 140 can respond to the user identification assertion request from the website 130. To do this, the security server 140 and the individual websites 130 in the 2CHK system have agreed in advance on different shared secrets for all users participating in the 2CHK system and visiting this website. . That is, the security server and each website 130 has a shared secret that is unknown to any user or other website and is not associated with any particular user.

ユーザが、認証を要求するウェブサイト130またはウェブサイトアプリケーション312に存在し、かつウェブサイト130またはウェブサイトアプリケーション212がこの要求をセキュリティサーバ140へ伝達する場合、セキュリティサーバ140は、ログインOTP、即ちログイン認証情報を、このウェブサイト130と共有される秘密および望ましい場合には所定の他の情報の関数として計算する。例えば、OTPは、タイムスタンプまたはカウンタベースのOTPアルゴリズムにも基づいて構築することができ、時間またはカウンタ値は、セキュリティサーバ140によってウェブサイト130またはウェブサイトアプリケーション212へ伝達され、または潜在的に、何らかの合意された公式を用いて確定的に計算される。セキュリティサーバ140は、次に、計算されたOTPを、例えばユーザのセキュリティウィンドウ120に表示するためにブラウザアプリケーション207またはセキュリティアプリケーション210、即ち2CHKクライアントへ伝達する。ユーザは、ウェブサイト130またはウェブサイトアプリケーション212に対してユーザを認証するために、この表示されたログインOTPを、ユーザのコンピュータ装置100上へブラウザ207またはウェブサイトアプリケーション212によって表示されているユーザ資格認定情報を要求するウェブサイトページの適切な部位に(例えば、切り取りおよび貼り付けまたはタイプ打ちによって)入力する。   If the user is in a website 130 or website application 312 that requires authentication, and the website 130 or website application 212 communicates this request to the security server 140, the security server 140 may login OTP, or login. The authentication information is calculated as a function of the secret shared with this website 130 and, if desired, certain other information. For example, the OTP can also be constructed based on a timestamp or counter-based OTP algorithm, where the time or counter value is communicated by the security server 140 to the website 130 or website application 212, or potentially Calculated deterministically using some agreed formula. The security server 140 then communicates the calculated OTP to the browser application 207 or the security application 210, i.e., the 2CHK client, for example for display in the user's security window 120. In order for the user to authenticate the user to the website 130 or the website application 212, the displayed login OTP is displayed on the user's computer device 100 by the browser 207 or the website application 212. Enter (e.g., by cutting and pasting or typing) the appropriate part of the website page requesting certification information.

入力されたログインOTPを受信した後、ウェブサイト130は、セキュリティサーバ140と共有する秘密を用いてOTPを再計算することによりユーザを認証する。したがって、2CHKシステムは、従来のOTPシステムにおける全ての安全特性を有し、しかも、各ユーザとの間に共有される秘密を要求せず、かつOTPを生成する目的で共有秘密を必要とするのはセキュリティサーバ140およびウェブサイト130のみであるという圧倒的な優位点を有する。   After receiving the entered login OTP, the website 130 authenticates the user by recalculating the OTP using the secret shared with the security server 140. Therefore, the 2CHK system has all the security characteristics of the conventional OTP system, and does not require a secret shared with each user, and requires a shared secret for the purpose of generating an OTP. Has the overwhelming advantage of being only the security server 140 and the website 130.

例えば、ある実用的なアプリケーションにおいて、ユーザは、ウェブサイト130における所定の情報にアクセスするために、ブラウザ207またはウェブサイトアプリケーション212を用いてウェブサイトウィンドウ110へ要求を入力する。要求は、ウェブサイトウィンドウ110から通信チャネル132を介してウェブサイト130へ送信される。ウェブサイト130は、この要求をセキュリティサーバ140へ、適宜、ユーザのブラウザアプリケーション207またはウェブサイトアプリケーション212を介し通信チャネル132および142を介して、または任意選択のウェブサイト130とセキュリティサーバ140との間の直接的な通信リンク134を介して、の何れかによって送信する。   For example, in one practical application, a user enters a request into website window 110 using browser 207 or website application 212 to access predetermined information on website 130. The request is sent from the website window 110 to the website 130 via the communication channel 132. The website 130 sends this request to the security server 140, via the user's browser application 207 or website application 212, via communication channels 132 and 142, or between the optional website 130 and the security server 140, as appropriate. Via any of the direct communication links 134.

セキュリティサーバ140は、ウェブサイト130に対してユーザを認証するために、ウェブサイトへログインするための個人識別番号(PIN)と称される場合もあるログインOTPを計算する。ログインOTPは、セキュリティサーバ140がこの特定のウェブサイト130と共有する秘密の関数として計算される。先に述べたように、この共有される秘密は、ユーザの知らないものであり、かつユーザまたは他のいかなる特定ユーザにも関連付けられているものではない。セキュリティサーバ140は、次に、このログインOTPをユーザのセキュリティウィンドウ120へ安全な通信チャネル144を介して送信する。   The security server 140 calculates a login OTP, sometimes referred to as a personal identification number (PIN) for logging into the website, to authenticate the user to the website 130. The login OTP is calculated as a secret function that the security server 140 shares with this particular website 130. As mentioned earlier, this shared secret is unknown to the user and is not associated with the user or any other specific user. The security server 140 then transmits this login OTP to the user's security window 120 via the secure communication channel 144.

ユーザは、このログインOTPを切り取って、ウェブサイトウィンドウ110内のウェブブラウザ207またはウェブサイトアプリケーション212によって表示されるウェブサイトページへ貼り付け、または切り取り・貼り付けに代えてコピーし、かつログインOTPは、通信チャネル132を介してウェブサイト130へ送信される。   The user cuts this login OTP and pastes it on the website page displayed by the web browser 207 or the website application 212 in the website window 110, or copies it instead of cutting and pasting. To the website 130 via the communication channel 132.

ウェブサイト130は、独自に、セキュリティサーバ140と共有する秘密を用いてログインパスワードを計算し、かつこれをユーザから受信されるものと比較する。両者が一致すれば、ウェブサイト130は、セキュリティサーバ140がアクセスを要求してきたユーザと同じユーザ(即ち、ユーザのふりをしている、セキュリティサーバ140への途中で要求を傍受した他の誰かではない)を認証している、と確信することができる。さらに、セキュリティサーバ140は、ユーザのログインOTPを独立したチャネル144内に示していることから、要求のユーザ確認が得られる。   The website 130 uniquely calculates a login password using a secret shared with the security server 140 and compares it with that received from the user. If they match, the website 130 is the same user that the security server 140 has requested access to (i.e. someone else pretending to be the user and intercepting the request on the way to the security server 140). You can be confident that you are authentic. Furthermore, the security server 140 indicates the user's login OTP in an independent channel 144 so that the requested user confirmation is obtained.

セキュリティアプリケーション、即ち2CHKクライアント210は、他のアプリケーション、例えばウェブサイトアプリケーション212または非ブラウザアプリケーション218と最も適切な方法を用いて通信するようにプログラムされ得ることは留意されるべきである。   It should be noted that the security application, i.e., 2CHK client 210, can be programmed to communicate with other applications, e.g., website application 212 or non-browser application 218, using the most appropriate method.

スマートフォンによる実現形態の固有の優位点は、iPhoneのオペレーティングシステム上のパブリックペーストボード等のパブリック共有記憶装置を用いる能力にある。したがって、ユーザがウェブサイトアプリ212へアクセスするという自身の希望を確認し、かつセキュリティサーバがログインOTP、即ちユーザのログイン認証情報をセキュリティアプリ210へ通信チャネル144を介して送信した後、セキュリティアプリは、このログインOTPをウェブサイトアプリ212へスマートフォン共有記憶装置210bを用いて転送する。しかしながら、望ましい場合には、ユーザは、OTPを自動的に記入してもらうのではなく、ログインOTPをセキュリティウィンドウ120からウェブサイトアプリ212によって表示されるウェブサイトページへ手動でコピーするように要求される可能性もあることは理解されるべきである。何れの場合も、表示されたウェブサイトページにOTPが記入された後、ユーザが「ログイン完了」をクリックすると、ウェブサイトアプリ212は、通信チャネル132を介してウェブサイト130へログインOTPを送る。   A unique advantage of the smartphone implementation is the ability to use a public shared storage device such as a public pasteboard on the iPhone operating system. Therefore, after the user confirms his / her desire to access the website application 212 and the security server sends the login OTP, ie, the user's login authentication information, to the security application 210 via the communication channel 144, the security application The login OTP is transferred to the website application 212 using the smartphone shared storage device 210b. However, if desired, the user is required to manually copy the login OTP from the security window 120 to the website page displayed by the website app 212, rather than having the OTP filled in automatically. It should be understood that this is possible. In any case, after the OTP is entered on the displayed website page, when the user clicks “login complete”, the website application 212 sends the login OTP to the website 130 via the communication channel 132.

ノンスログインおよびTTLは、有益なことには、パブリック記憶装置210bにおけるセキュリティアプリ、即ち2CHKクライアント210のパブリックペーストボードへ書き込まれることが可能である。ログインOTPは、有益なことには、ペーストボードへ、マーチャントid.PINと称される場合もある、ウェブサイト識別子とPINとの組合せを用いて書き込まれることも可能である。マーチャントid.PINは、先に書き込まれたあらゆるマーチャントid.PINへ上書きされる。また、ウェブサイトアプリケーション212は、ユーザの、または任意の特定ユーザに関連づけられる、有効なTTLを伴うログインノンスを有するセキュリティアプリケーション210のパブリックペーストボードが存在するかどうかをチェックすることも留意されるべきである。存在しなければ、それはユーザに、ユーザが2CHKシステムにログインしているようには思われないことを知らせる。   The nonce login and TTL can be beneficially written to the security app in the public storage device 210b, ie, the public pasteboard of the 2CHK client 210. The login OTP is beneficially to the pasteboard, merchant id. It can also be written using a combination of website identifier and PIN, sometimes referred to as PIN. Merchant id. The PIN is any merchant id. Overwritten to PIN. It should also be noted that the website application 212 checks whether there is a public pasteboard for the security application 210 with a login nonce with a valid TTL associated with the user or any particular user. It is. If not, it informs the user that the user does not appear to be logged into the 2CHK system.

ログイン認証の場合、セキュリティアプリ、即ち2CHKクライアント210は、商業者および認証要求に関する情報をセキュリティサーバ140へ送信する。送信は、ログインノンスを含む。ウェブサイトアプリ212は、セキュリティアプリケーション、即ち2CHKクライアント210のペーストボードをポーリングして新しいマーチャントid.PINが存在するかどうかを確認する。ウェブサイトアプリケーション212は、これを見つけると、ウェブサイト130へストリングおよびログインOTPの送信を行う。ウェブサイト130は、ログインOTPに関するその固有の検証を行った後に、成功または失敗メッセージを戻す。
トランザクション承認(例えば、トランザクション署名)段階
In the case of login authentication, the security application, that is, the 2CHK client 210 transmits information regarding the merchant and the authentication request to the security server 140. The transmission includes a login nonce. The website application 212 polls the pasteboard of the security application, that is, the 2CHK client 210, to check the new merchant id. Check if the PIN exists. When found, the website application 212 sends a string and login OTP to the website 130. The website 130 returns a success or failure message after performing its own verification of the login OTP.
Transaction approval (eg transaction signature) stage

ウェブサイト130は、ユーザのブラウザ110から確認を希望するというトランザクション要求を受信すると、先に論じたように、トランザクション情報をセキュリティサーバ140へ、ユーザのブラウザ110を介して、またはウェブサイト130とセキュリティサーバ140との間の直接的な通信チャネル134を介して、の何れかで送る。セキュリティサーバ140は、次に、このトランザクション情報をユーザのセキュリティウィンドウ120へ、トランザクションへのユーザ署名として機能するトランザクションOTP、即ちトランザクション署名と共に転送する。トランザクションOTPは、セキュリティサーバ140により、セキュリティサーバ140とウェブサイト130との間で共有される秘密、およびトランザクション情報、および望ましい場合には、タイムスタンプまたはカウンタベースのOTPアルゴリズム等の他の情報に基づいて計算される。先に述べたように、共有される秘密は、ユーザには知られず、かついかなる特定ユーザにも関連付けられるものではない。即ち、ユーザ毎の共有秘密に対する要求事項は存在しない。   When website 130 receives a transaction request for confirmation from the user's browser 110, the transaction information is passed to the security server 140 via the user's browser 110 or security with the website 130, as discussed above. Send either via a direct communication channel 134 with the server 140. The security server 140 then forwards this transaction information to the user's security window 120 along with a transaction OTP that functions as a user signature for the transaction, i.e., a transaction signature. The transaction OTP is based on the secret shared by the security server 140 between the security server 140 and the website 130, and transaction information, and other information such as a timestamp or counter-based OTP algorithm, if desired. Is calculated. As mentioned earlier, the shared secret is not known to the user and is not associated with any particular user. That is, there is no requirement for a shared secret for each user.

ユーザは、このトランザクションOTP、即ちトランザクション署名を、ウェブサイトウィンドウ110を介してウェブサイト130へ転送する。   The user transfers this transaction OTP, that is, the transaction signature, to the website 130 via the website window 110.

ウェブサイトは、トランザクションOTP、即ちトランザクション署名を再計算し、ウェブサイト130により計算されたOTPとウェブサイトウィンドウ110から受信されたOTPとが一致すれば、ウェブサイトは、ユーザがトランザクションを追認したことを確信することができる。   The website recalculates the transaction OTP, ie the transaction signature, and if the OTP calculated by the website 130 matches the OTP received from the website window 110, the website has confirmed the transaction by the user. Can be sure.

実用的なアプリケーションにおいて、ウェブサイト130を訪れているユーザは、ブラウザアプリケーション207またはウェブサイトアプリケーション212によりウェブサイトウィンドウ110によって表示されているウェブサイト130のウェブページからトランザクション、例えば「アリスに100ドル支払う」を選択し、これがウェブサイトウィンドウ110から通信チャネル132を介してウェブサイト130へ送信される。ウェブサイト130は、このトランザクションをセキュリティサーバ140へ、適宜、通信チャネル132および142を介したユーザのブラウザ207を介して、またはウェブサイト130とセキュリティサーバ140との間の直接的な通信チャネル134を介して、の何れかで送信する。   In a practical application, a user visiting the website 130 may make a transaction from the web page of the website 130 displayed by the website window 110 by the browser application 207 or the website application 212, eg, “pay $ 100 to Alice. This is transmitted from the website window 110 to the website 130 via the communication channel 132. The website 130 passes this transaction to the security server 140 via the user's browser 207 via the communication channels 132 and 142, or the direct communication channel 134 between the website 130 and the security server 140, as appropriate. Via either of them.

セキュリティサーバ140は、トランザクション署名、即ちトランザクションOTPを、(i)トランザクション詳細、(ii)その特定のウェブサイト130と共有する秘密、および場合により他の情報、の関数として計算する。セキュリティサーバ140は、次に、このトランザクション署名をユーザのセキュリティウィンドウ120へ通信チャネル144を介して、かつ妥当であれば通信リンク320を介して送信する。   The security server 140 calculates the transaction signature, or transaction OTP, as a function of (i) transaction details, (ii) secrets shared with that particular website 130, and possibly other information. The security server 140 then transmits this transaction signature to the user's security window 120 via the communication channel 144 and, if appropriate, via the communication link 320.

ユーザは、このトランザクション署名を切り取って、ブラウザ207またはウェブサイトアプリケーション212によりウェブサイトウィンドウ110に表示されるウェブサイト130のウェブサイトページへ貼り付け、または切り取り・貼り付けに代えてコピーし、このトランザクション署名は、通信チャネル132を介してウェブサイト130へ送信される。ウェブサイト130は、独自にトランザクション署名を、(i)トランザクション詳細、(ii)セキュリティサーバ140と共有する秘密、および妥当であれば他の情報を用いて計算し、これを、ユーザから受信されたものと比較する。2つのトランザクション署名が一致すれば、ウェブサイト130は、セキュリティサーバ140は送信したものと同じトランザクション(即ち、セキュリティサーバ140への途中で操作されたトランザクションではない)を目にしていることを確信することができ、かつセキュリティサーバ140はユーザにトランザクションを独立したチャネル144において示していることから、トランザクションのユーザ追認も得られていることを確信することができる。   The user cuts the transaction signature and pastes it on the website page of the website 130 displayed on the website window 110 by the browser 207 or the website application 212, or copies it instead of cutting and pasting, and copies the transaction signature. The signature is transmitted to the website 130 via the communication channel 132. The website 130 calculates its own transaction signature using (i) transaction details, (ii) secrets shared with the security server 140, and other information if appropriate and received from the user. Compare with things. If the two transaction signatures match, the website 130 is confident that the security server 140 sees the same transaction that it sent (ie, it was not a transaction that was manipulated on the way to the security server 140). And because the security server 140 presents the transaction to the user in an independent channel 144, it can be assured that user confirmation of the transaction has also been obtained.

要約すれば、ユーザと、識別プロバイダとして作用するセキュリティサーバ140と、ネットワーク上で行われる、ウェブサイトにおけるユーザによる製品購入または送金等のトランザクションの場合の依拠当事者であるウェブサイト130との間の結び付きは、著しく強化される。繰り返すが、本システムがOTPの全ての安全特性を有し、しかも、各ユーザとの間の共有秘密を必要とせず、かつトランザクションへの署名として使用されるOTPを生成する目的で共有秘密を必要とするのはセキュリティサーバ140およびウェブサイト130等の各ウェブサイトのみである、という著しい優位点を有することは理解されるべきである。同じく先に述べたように、実際のOTPは、望ましい場合には、タイムスタンプまたはカウンタベースのOTPアルゴリズム(例えば、時間またはカウンタ値がセキュリティサーバ140によってウェブサイト130へ伝達されるように使用されるアルゴリズム)に基づいて構築されることも可能であり、または潜在的に、何らかの合意された公式を用いて確定的に計算されることが可能である。   In summary, the connection between the user, the security server 140 acting as an identity provider, and the website 130 that is the relying party in case of a transaction such as a product purchase or remittance by the user on the website that takes place over the network. Is significantly enhanced. Again, this system has all the security features of OTP, does not require a shared secret with each user, and requires a shared secret for the purpose of generating an OTP used as a signature for a transaction It should be understood that there is a significant advantage that only each website, such as security server 140 and website 130, is. As also mentioned above, the actual OTP is used if desired, such as a timestamp or counter-based OTP algorithm (eg, time or counter value is communicated by the security server 140 to the website 130). Algorithm) or potentially calculated deterministically using some agreed upon formula.

また同じく、先にも述べたように、コンピュータ装置100がスマートフォンまたは他のスマートモバイル通信デバイスである場合、所定の動作は、望ましい場合には、所定の一般的なスマートフォン機能および性能を利用するように達成されてもよい。   Similarly, as described above, when the computer apparatus 100 is a smartphone or other smart mobile communication device, the predetermined operation may be performed using a predetermined general smartphone function and performance, if desired. May be achieved.

スマートフォンにより達成することの固有の優位点は、iPhoneのオペレーティングシステム上のパブリックペーストボード等のパブリック共有記憶装置を用いる能力にある。したがって、ウェブサイトアプリ212は、通信チャネル142を介してトランザクションをセキュリティサーバ140へ送信し、かつまた、ユーザにセキュリティウィンドウ120におけるトランザクションの承認も求める。これは、トランザクションを承認するためにPayPal(商標)等の支払いウェブサイトへユーザがリダイレクトされることに類似する。セキュリティサーバ140は、トランザクションを、ユーザへ提示するために通信チャネル144を介してセキュリティアプリ、即ち2CHKクライアント210へ送信する。ユーザがセキュリティサーバ140に対してトランザクションを進めるというその希望を追認し、かつセキュリティサーバがトランザクションOTP、即ちトランザクション署名を、セキュリティアプリ、即ち2CHKクライアント210へ通信チャネル144を介して送信した後、セキュリティアプリ210は、スマートフォン共有記憶装置210bを用いてウェブサイトアプリ212へトランザクションOTPを転送する。しかしながら、望ましい場合には、ユーザは、OTPを自動的に記入してもらうのではなく、トランザクションOTPをセキュリティウィンドウ120からウェブサイトアプリ212によって表示されるウェブサイトウィンドウに提示されるページへ手動でコピーするように要求される可能性もあることは理解されるべきである。何れの場合も、表示されたウェブサイトページにOTPが記入された後、ユーザが「ログイン完了」をクリックすると、ウェブサイトアプリ212は、通信チャネル132を介してウェブサイト130へトランザクションOTPを送る。   A unique advantage of achieving with a smartphone is the ability to use a public shared storage device such as a public pasteboard on the iPhone operating system. Accordingly, the website application 212 sends the transaction to the security server 140 via the communication channel 142 and also asks the user to approve the transaction in the security window 120. This is similar to redirecting the user to a payment website such as PayPal ™ to approve the transaction. The security server 140 sends the transaction to the security app, ie the 2CHK client 210, via the communication channel 144 for presentation to the user. After the user confirms his / her desire to proceed with the transaction to the security server 140 and the security server sends the transaction OTP, i.e. the transaction signature, to the security application, i.e. 2CHK client 210, via the communication channel 144, the security application 210 transfers the transaction OTP to the website application 212 using the smartphone shared storage device 210b. However, if desired, the user manually copies the transaction OTP from the security window 120 to a page presented in the website window displayed by the website app 212, rather than having the OTP filled in automatically. It should be understood that it may be required to do so. In either case, after the OTP is entered on the displayed website page, when the user clicks “login complete”, the website application 212 sends a transaction OTP to the website 130 via the communication channel 132.

ログインOTPの場合と同様に、トランザクションOTPも、有益なことには、ウェブサイト商業者識別子、即ちマーチャントidおよびPINの組合せを用いてペーストボードへ書き込まれることが可能である。マーチャントid.PINは、先に書き込まれたあらゆるマーチャントid.PINに上書きされる。また、ウェブサイトアプリ212は、セキュリティアプリ、即ち2CHKクライアント210のパブリックペーストボードが存在するかどうかをチェックし、存在すれば、ペーストボードをポーリングして新しいトランザクションOTPが存在するかどうかを確認することも留意されるべきである。ウェブサイトアプリ212は、これを見つけると、ウェブサイト130へ送信を行う。ウェブサイト130は、トランザクションOTPに関するその固有の検証を行った後に、成功または失敗メッセージを戻す。   As with the login OTP, the transaction OTP can be beneficially written to the pasteboard using a combination of website merchant identifiers, ie merchant id and PIN. Merchant id. The PIN is any merchant id. Overwritten on PIN. In addition, the website application 212 checks whether there is a security application, that is, a public pasteboard of the 2CHK client 210, and if so, polls the pasteboard to check whether a new transaction OTP exists. Should also be noted. When the website application 212 finds this, it transmits to the website 130. The website 130 returns a success or failure message after performing its own verification of the transaction OTP.

セキュリティウィンドウに表示する目的でセキュリティサーバのブラウザアプリケーション207またはセキュリティアプリケーション210または310から送信されるトランザクション情報の完全性をさらに保護するために、トランザクション情報は、検出、特に送信される情報の一部のみの検出もなしには改竄が困難であるプレゼンテーション形式を利用して送られることが可能である。この点に関して、改竄は、テキストよりも音声記録および画像の方が遙かに困難である。   In order to further protect the integrity of the transaction information sent from the security server browser application 207 or security application 210 or 310 for display in the security window, the transaction information is detected, especially only a part of the information sent. It can be sent using a presentation format that is difficult to falsify without detecting. In this regard, tampering is much more difficult with audio recording and images than with text.

例えば、複雑な音声操作ソフトウェアおよびユーザが認識可能な同じ音声へのアクセスまたは知識の双方を有する攻撃者でなければ、セキュリティサーバ140において作成された、ユーザが認識可能な特有の音声で発生される「ジョンへの1000ドルの支払いに同意する場合は、34567を入力してください」という言い回しの音声記録を「エバンへの1000ドルの支払いに同意する場合は、34567を入力してください」に変更することは極めて困難であると思われる。セットアップの間にユーザにより選択されるもの等の特有の音声または背景画がユーザとの双方向通信において一貫して使用されれば、如何なる変更もユーザによってより容易に検出されるものと思われる。   For example, unless an attacker has both complex voice manipulation software and access or knowledge to the same voice that the user can recognize, it is generated with a unique voice that can be recognized by the user created in the security server 140 Changed the voice recording of the phrase "Enter 34567 if you agree to pay $ 1000 to John" to "Enter 34567 if you agree to pay $ 1000 to Evan" It seems to be extremely difficult to do. It is likely that any change will be more easily detected by the user if a unique voice or background image, such as that selected by the user during setup, is used consistently in two-way communication with the user.

本発明の別の態様によれば、トランザクション詳細は、ユーザには理解できるが連続したテキストよりも操作が困難な形式で提示される。例えば、トランザクション詳細は、セキュリティウィンドウ110において、トランザクション詳細が内部に埋め込まれたユーザ認識可能音声の音声ストリームとして、またはトランザクション詳細が内部に埋め込まれたユーザ認識可能背景を利用する画像として提示されることが可能である。さらに、情報は、先に述べたように、セキュリティウィンドウ110において、音声ストリームおよびピクチャの双方を含むマルチメディア提示として提示されることが可能である。この場合、ユーザは次に、提示されたトランザクション詳細とユーザがトランザクション詳細であると理解するものとが一致するか否かを決定する前に、この提示からトランザクション詳細を抽出するように要求される。またさらに、セキュリティサーバは、コンテンツを、例えば感知された、または決定されたリスクに依存して、テキストのみ、または画像のみ、または音声ストリームのみ、または画像と音声ストリームとを含むマルチメディア、またはマルチメディアのオプションが付いたテキスト、またはテキストのオプションが付いたマルチメディア、他を含む様々な方法のうちの任意の方法で提示するように構成されることが可能である。   According to another aspect of the invention, transaction details are presented in a form that is understandable to the user but more difficult to manipulate than continuous text. For example, transaction details are presented in security window 110 as an audio stream of user-recognizable audio with transaction details embedded therein or as an image that utilizes a user-recognizable background with transaction details embedded therein. Is possible. In addition, the information can be presented in the security window 110 as a multimedia presentation that includes both audio streams and pictures, as described above. In this case, the user is then required to extract transaction details from this presentation before determining whether the presented transaction details match what the user understands as transaction details. . Still further, the security server can determine whether the content is multimedia, including text only, or only images, or only audio streams, or images and audio streams, depending on the perceived or determined risk, for example. It can be configured to be presented in any of a variety of ways, including text with media options, multimedia with text options, etc.

また、2CHKシステムは、ユーザが開始するトランザクション用に適合されることも可能である。しかしながら、このようなトランザクションは、典型的には、2CHKシステムとの関連付けを有するユーザ、即ちセキュリティサーバ140との間に事前に確立されかつ現時点で機能している関連付けを有するユーザに限定される。また、ユーザが開始するトランザクションも、典型的には、2CHKシステムとの関連付けを有する企業、即ちセキュリティサーバ140と共に2CHKログインおよび/またはトランザクションOTPの生成に使用される秘密を共有する企業等の、セキュリティサーバ140との間に事前に確立されかつ現時点で機能している関連性を有する企業に限定される。   The 2CHK system can also be adapted for user initiated transactions. However, such transactions are typically limited to users having an association with the 2CHK system, i.e., having a pre-established and currently functioning association with the security server 140. Also, user-initiated transactions typically involve security, such as a company that has an association with a 2CHK system, i.e., a company that shares a security used with the security server 140 to generate a 2CHK login and / or transaction OTP. It is limited to companies that have a relationship established with the server 140 in advance and functioning at the present time.

より具体的には、このモデルにおいて、エンドユーザは、セキュリティアプリケーション、即ち2CHKクライアント210または310を介して、例えばウェブサイト130により代表される存在である企業とのトランザクションを開始する。これを行うために、ユーザは、先に述べたように、そのコンピュータ装置または補助的ハードウェア上のセキュリティアプリケーション210または310を起動する。   More specifically, in this model, the end user initiates a transaction with a company that is represented by, for example, the website 130 via the security application, ie, the 2CHK client 210 or 310. To do this, the user launches the security application 210 or 310 on the computer device or auxiliary hardware as described above.

起動段階が首尾良く完了した後、ユーザは、例えばセキュリティウィンドウ120において利用可能な参加企業のプルダウンリストから、ユーザが開始を希望するトランザクションの相手企業を選択することができる。またユーザは、例えばセキュリティウィンドウ120において利用可能なプルダウンリストから、開始されるべきトランザクションのタイプ、例えば送金、残高照会、商品購入、情報受信またはクーポン入手、他、も選択する。ユーザは、次に、セキュリティウィンドウ120においてこのトランザクションタイプに関連する情報を入力し、送信を押す。企業およびトランザクションタイプの識別に加えて、関連するトランザクション情報は、例えば、(i)転送されるべき金額、送金元口座および送金先口座の口座番号、または(ii)残高照会が希望される口座の口座番号、または(iii)購入されるべき商品の識別子、その価格およびその配送先であり得る。メッセージおよびコンテンツの構成は、例えば、クイックレスポンス(QR)コードまたはNFCスキャンから拾い出されてもよい。   After the startup phase has been successfully completed, the user can select the partner company of the transaction that the user wishes to start from, for example, a pull-down list of participating companies available in the security window 120. The user also selects, for example, from the pull-down list available in the security window 120, the type of transaction to be initiated, such as remittance, balance inquiry, purchase of goods, receipt of information or coupon acquisition, etc. The user then enters information related to this transaction type in the security window 120 and presses send. In addition to identifying the company and transaction type, the associated transaction information can include, for example, (i) the amount to be transferred, the account number of the source and destination accounts, or (ii) the account for which balance inquiry is desired. It may be an account number, or (iii) an identifier for the item to be purchased, its price and its shipping address. Message and content composition may be picked up from, for example, a quick response (QR) code or an NFC scan.

入力されたトランザクション情報は、通信チャネル144を介して、かつ妥当であれば通信リンク320を介してセキュリティサーバ140へ送信される。セキュリティサーバは、次に、このトランザクション情報を例えばウェブサイト130である適切な企業へ通信チャネル134を介して転送する。所定の実現形態において、セキュリティサーバは、トランザクション情報と共に、ユーザに関するリスク情報も送信することが望ましい場合がある。何れにしても、企業は、例えばログイン認証およびトランザクション署名のためのユーザによるセキュリティアプリケーション、即ち2CHKクライアント210または320の進行中の使用に基づいて、適用可能なユーザと2CHKシステムとの間に既存の関連付けが存在することを通知されるか、事前に気づかされている。したがって、企業は、要求者との信用(2CHK関連付け)を有する存在、即ちセキュリティサーバ140から、認識可能なコンテンツを有する構造化されたメッセージにおいてトランザクション要求を受信するのが有利である。   The entered transaction information is transmitted to the security server 140 via the communication channel 144 and, if appropriate, via the communication link 320. The security server then forwards this transaction information to the appropriate company, eg, website 130, via communication channel 134. In certain implementations, it may be desirable for the security server to send risk information about the user along with the transaction information. In any case, an enterprise may use existing security applications by a user for login authentication and transaction signing, i.e. based on the ongoing use of 2CHK clients 210 or 320, between existing users and 2CHK systems. You are informed that the association exists or have been noticed in advance. Thus, it is advantageous for an enterprise to receive a transaction request in a structured message with recognizable content from a presence that has trust (2CHK association) with the requester, ie, security server 140.

例えばウェブサイト130である企業は、トランザクション要求を受け入れるか拒絶することができ、かつ通信チャネル134を介してセキュリティサーバ140へステータスを返す。セキュリティサーバ140は、このステータスメッセージをセキュリティアプリケーション、即ち2CHKクライアント210または310へ通信チャネル144を介して、かつ妥当であれば通信リンク320を介して送る。セキュリティアプリケーションは、ステータスメッセージをセキュリティウィンドウ120においてユーザに提示する。   For example, a company that is a website 130 can accept or reject the transaction request and return a status to the security server 140 via the communication channel 134. The security server 140 sends this status message to the security application, ie the 2CHK client 210 or 310, via the communication channel 144 and, if appropriate, via the communication link 320. The security application presents status messages to the user in the security window 120.

望ましい場合には、例えばウェブサイト130である企業は、トランザクション要求を受け入れる、または拒絶する前に、OOBA、KBAまたはテキストメッセージのトランザクションOTPによるユーザの追加認証も要求してもよい。その場合、ユーザは、(i)セキュリティウィンドウ120において、要求された情報(例えば、ユーザがOOBAサーバ150を介してセキュリティサーバ140から受信したトランザクションOTP、または例えばウェブサイト130である企業から直接受信したテキストメッセージ内のトランザクションOTP)を入力するか、または(ii)企業から直接電話を受ける。OTPが入力されれば、これは、セキュリティウィンドウ120からセキュリティサーバ140を介して例えばウェブサイト130である企業へ転送される。   If desired, for example, a company that is a website 130 may also require additional authentication of the user with an OOBA, KBA or text message transaction OTP before accepting or rejecting the transaction request. In that case, the user received (i) the requested information (eg, the transaction OTP that the user received from the security server 140 via the OOBA server 150 or directly from the company that is the website 130, for example) in the security window 120 Enter the transaction OTP) in a text message or (ii) receive a call directly from the company. If the OTP is entered, it is transferred from the security window 120 via the security server 140 to, for example, a company that is the website 130.

例えばウェブサイト130である企業は、返されたOTPに基づいて、またはユーザが電話呼を取ることに基づいてトランザクションを完了するか否かを決定し、通信チャネル134を介してセキュリティサーバ140へステータスを返す。セキュリティサーバ140は、次に、このステータス情報を、セキュリティウィンドウ120における表示のためにセキュリティアプリケーション、即ち2CHKクライアント210または310へ送る。
問い合わせ型トランザクション
For example, a company that is a website 130 determines whether to complete a transaction based on the returned OTP or based on the user taking a telephone call, and status to the security server 140 via the communication channel 134. return it. The security server 140 then sends this status information to the security application, ie the 2CHK client 210 or 310, for display in the security window 120.
Inquiry type transaction

「問い合わせ型」トランザクションは、ユーザが、自分がユーザであると言う者であることについてさらに大きな信頼を与えるために実行されることが可能である。より具体的には、「問い合わせ型」トランザクションは、セキュリティサーバ140に対し、安全な通信チャネル144を利用して、企業が、共有秘密、居場所情報および生体情報識別子を含むが但しこれらに限定されないウェブサイト130によるアクセスが可能な識別情報と、比較できる追加的な認証情報を、捕捉するように要求することによって、識別の結び付きにおいて適用可能な企業を「堅固にする」、即ち適用可能な企業にさらなる信頼を与えるために、例えばウェブサイト130である任意の企業によりセキュリティサーバ140へ通信チャネル134またはチャネル132および142を介して、任意の後続する時間に、即ち起動後に送られることが可能である。   A “query-type” transaction can be performed to give the user greater confidence that he is the person who says he is the user. More specifically, an “inquiry” transaction uses a secure communication channel 144 to the security server 140 to allow a company to include, but is not limited to, a shared secret, location information, and biometric identifier. By making it necessary to capture identification information that can be accessed by the site 130 and additional authentication information that can be compared, it “makes” the company that is applicable in the identification chain, that is, to become an applicable company. To give further confidence, it can be sent to the security server 140 by any company, for example the website 130, via the communication channel 134 or channels 132 and 142 at any subsequent time, ie after activation. .

例えばウェブサイト130である企業は、指標としてユーザの電話番号またはそのハッシュを用いて、通知/追認/署名/問い合わせトランザクションを送ることができる。したがって、複数の関連付けを用いて識別の結び付きを堅固にすることができる。   For example, a company that is a website 130 can send a notification / verification / signature / query transaction using the user's phone number or its hash as an indicator. Thus, identification associations can be tightened using multiple associations.

例えば、ユーザが既にセキュリティサーバ140によって検証されかつ安全な通信チャネル144が確立された後の任意の時点で、ウェブサイト130は、安全な通信チャネル134または通信チャネル132および142を介してセキュリティサーバ140へ問い合わせを送信し、ユーザに、「あなたの郵便番号は何ですか?」または「好きな色は何ですか?」または「あなたの企業パスワードは何ですか?」等の1つまたは複数の質問または企業自体が、ユーザとの間に既に有する個別の関連性を介して企業が知る情報に基づいてセキュリティサーバ140により安全な通信チャネル144を介して通信相手であるユーザを別個に認証できるようにする他の何らかの1つまたは複数の問い合わせをすることができる。セキュリティサーバ140は、受信された企業の問い合わせを、セキュリティウィンドウ120においてユーザへ提示するために、安全な通信チャネル144を介してユーザへ送信する。ユーザは、提示された企業の問い合わせに対する回答をセキュリティウィンドウ120に入力し、セキュリティアプリケーションは、安全な通信チャネル140を介するセキュリティサーバ140への回答の送信を指令する。セキュリティサーバ140は、さらに、受信された回答をウェブサイト130へ、安全な通信チャネル134を介して、またはチャネル132および142を介して送信する。ウェブサイト130は、次に、受信された回答を、ユーザをさらに認証するために、即ちユーザが実際に、自分がユーザであると言う者であることをさらに追認するために知っている問い合わせに対する正解と比較する。
システムアーキテクチャの柔軟性
For example, at any point after the user has already been verified by the security server 140 and the secure communication channel 144 has been established, the website 130 can be accessed via the secure communication channel 134 or the communication channels 132 and 142 via the security server 140. Send an inquiry to the user and ask one or more of “What is your postal code?” Or “What is your favorite color?” Or “What is your corporate password?” Allows the security server 140 to separately authenticate the user with whom it is communicating via the secure communication channel 144 based on information that the company knows through the individual relationship that the question or company already has with the user Any other one or more queries can be made. The security server 140 sends the received corporate inquiry to the user via the secure communication channel 144 for presentation to the user in the security window 120. The user enters an answer to the presented company inquiry in the security window 120, and the security application commands the sending of the answer to the security server 140 via the secure communication channel 140. The security server 140 further transmits the received answer to the website 130 via the secure communication channel 134 or via the channels 132 and 142. The website 130 then responds to the query that the received answer knows to further authenticate the user, i.e., to further confirm that the user is actually a person who says he is the user. Compare with correct answer.
System architecture flexibility

本システムは、ウェブサイト130が任意の所定のトランザクションに適するフォームファクタを要求または選択することを可能にする柔軟なアーキテクチャで実現されることが可能である。例えば、ユーザは、2つ以上の異なるタイプのコンピュータ装置上に、例えばそのスマートフォン、デスクトップおよび/または補助的ハードウェア上で同時に実行されるセキュリティウィンドウ110を同時に有することができる。大部分のトランザクションは、そのデスクトップのセキュリティウィンドウ110へ送られることが可能(それが遙かに便利)であるが、よりリスクの高いトランザクションは、そのスマートフォンのセキュリティウィンドウ110へ送られることが可能である。最もリスクの高いトランザクションは、その補助的ハードウェアへと送られる場合もある。   The system can be implemented with a flexible architecture that allows the website 130 to request or select a form factor suitable for any given transaction. For example, a user may have security windows 110 running simultaneously on two or more different types of computing devices, for example on their smartphones, desktops and / or auxiliary hardware. Most transactions can be sent to the desktop security window 110 (which is much more convenient), but more risky transactions can be sent to the smartphone security window 110. is there. The highest risk transaction may be sent to its ancillary hardware.

再度、図1を参照すると、図示されているように、各ウェブサイト130は、ウェブサイト130上で動作可能なセキュリティアプリケーションのプログラミングインタフェース(API)135を有するのが有利である。ユーザが任意のウェブサイト130を訪れている場合、ユーザは、セキュリティAPI135を用いて、セキュリティウィンドウ110を介してセキュリティサーバ140へ暗号化されたトランザクションを送ることによりトランザクション認証を要求することができる。   Referring again to FIG. 1, as shown, each website 130 advantageously has a security application programming interface (API) 135 operable on the website 130. If the user is visiting any website 130, the user can request transaction authentication using the security API 135 by sending an encrypted transaction to the security server 140 via the security window 110.

先に述べたように、セキュリティウィンドウ110は、少なくとも3つのフォームファクタ、即ち(1)デスクトップまたはラップトップ・コンピュータ装置上で実行されるブラウザアプリケーション207によって制御され、ソフトウェアのダウンロードを必要としないポップアップ・セキュリティ・ウィンドウ、(2)スマートフォンまたは他のスマートモバイル通信デバイス上、または補助的ハードウェア上で実行されるセキュリティアプリケーション、即ち2CHKクライアント210(「セキュリティアプリ」210と称されることが多い)によって制御されるセキュリティウィンドウ、および(3)デスクトップまたはラップトップ・コンピュータ装置上で実行されるセキュリティアプリケーション、即ち2CHKクライアント210によって制御されるセキュリティウィンドウ、のうちの任意の1つで実現されることが可能である。   As mentioned earlier, the security window 110 is controlled by at least three form factors: (1) a browser application 207 running on a desktop or laptop computer device and does not require a software download. Controlled by a security window, (2) a security application running on a smartphone or other smart mobile communication device, or on auxiliary hardware, i.e. 2CHK client 210 (often referred to as "security app" 210) Security window, and (3) a security application running on a desktop or laptop computer device, ie a 2CHK client Security window controlled by 10, it can be implemented in any one of the.

同一のユーザは、有益なことには、異なる時間に異なるフォームファクタを用いることができる。例えば、セキュリティアプリケーション、即ち2CHKクライアント210をデスクトップ上にインストールしていて、ほとんどの時間にこれを用いるユーザは、他の何らかのデスクトップにあるブラウザ・ポップアップ・セキュリティ・ウィンドウを用いることができる(ローミング)。所定の高リスクのトランザクションでは、ウェブサイトは、ユーザのスマートフォン上で実行されるセキュリティアプリ210によって制御されるセキュリティウィンドウ120上にトランザクションを示すことを要求する場合もあり、一方で大部分のトランザクションは、ユーザのデスクトップ上で実行されるセキュリティアプリケーション210によって制御されるセキュリティウィンドウ120に示される。ソフトトークンとは異なり、セキュリティウィンドウ120または2CHKクライアント自体は、いかなるユーザ秘密をも含まない。フォームファクタに依存して、セキュリティウィンドウ120は、ブートアップ時間においてユーザに対して自動的に開始されることが可能であり、または、例えばデスクトップまたはスマートフォン上、または例えばブラウザ・ポップアップ・バージョンの場合のブックマーク上で実行されるセキュリティアプリケーション、即ち2CHKクライアント210に対しては、ユーザがアプリケーションアイコンをクリックすることによって手動で開始されることが可能である。   The same user can beneficially use different form factors at different times. For example, a security application, i.e. a 2CHK client 210 installed on a desktop and using it most of the time, can use a browser pop-up security window on some other desktop (roaming). For a given high-risk transaction, the website may require the transaction to be displayed on a security window 120 controlled by the security app 210 running on the user's smartphone, while most transactions are , Shown in a security window 120 controlled by a security application 210 running on the user's desktop. Unlike soft tokens, the security window 120 or the 2CHK client itself does not contain any user secrets. Depending on the form factor, the security window 120 can be automatically started for the user at boot-up time, or for example on a desktop or smartphone, or for example in the case of a browser pop-up version For a security application running on a bookmark, i.e. 2CHK client 210, it can be started manually by the user clicking on the application icon.

先に詳しく論じたように、ユーザは、セキュリティウィンドウ120に表示されるログインOTPまたはトランザクションOTPを切り取って、OTPを要求する、ブラウザ207またはウェブサイトアプリケーション212により表示されるウェブサイトウィンドウ110へ貼り付ける、または他の方法で挿入することができる。ユーザは、セキュリティウィンドウ120を介してセキュリティサーバ140へ、トランザクションが有効/無効であることを、例えばユーザがトランザクションを進めることを希望する、またはトランザクションの確認を拒絶する、という確認を行なうことによって伝えることもできる。しかしながら、セキュリティウィンドウ120が単にユーザにトランザクションを示すためにも使用され得ることは認識されるべきである。したがって、セキュリティウィンドウ120は、異なる形式を取ることができき、例えば、ある形式では、ユーザにトランザクションの表示を提示しかつユーザにウェブサイトへログインする、またはウェブサイトとのトランザクションに署名するためのOTPを提供し、別の形式では、ユーザにトランザクションの表示を提示しかつユーザによるトランザクションの確認を要求し、かつさらに別の形式では、単にユーザにトランザクションの表示を提示し、ユーザはさらなる行動を何ら要求されない。   As discussed in detail above, the user cuts the login OTP or transaction OTP displayed in the security window 120 and pastes it into the website window 110 displayed by the browser 207 or website application 212 that requests the OTP. Or can be inserted in other ways. The user informs the security server 140 via the security window 120 that the transaction is valid / invalid, for example by making a confirmation that the user wishes to proceed with the transaction or refuses to confirm the transaction. You can also. However, it should be appreciated that the security window 120 can also be used simply to indicate a transaction to the user. Thus, the security window 120 can take different forms, for example, in one form for presenting a display of the transaction to the user and logging the user into the website or signing a transaction with the website. OTP is provided, and in another form, the user is presented with an indication of the transaction and the user is asked to confirm the transaction, and in another form, the user is simply presented with an indication of the transaction, and the user takes further action Nothing is required.

ウェブサイト130へ参加すると、セキュリティAPI135は、下記の機能ステップを遂行するように実行されるのが有利である。
1.ウェブサイト130がtransaction_request()APIを呼び出し、transaction_request()APIは暗号化されたtransaction_requestを返す。トランザクション自体(単にトランザクションOTPの要求でもあり得る)に加えて、ウェブサイト130は、(i)単にユーザにトランザクションを表示すること、または(ii)ユーザがセキュリティウィンドウ110において「OK」をクリックする、またはユーザがセキュリティウィンドウ110に表示されるトランザクションを承認するという何らかの対応する指示を提供することを保証すること、または(iii)トランザクション署名を入手すること、の何れを希望するかを示す。
2.暗号化されたトランザクションは、次に、セキュリティサーバ140へ、ユーザのブラウザ207またはウェブサイトアプリケーション212を介して、またはセキュリティサーバ140とウェブサイト130との間の直接的な通信チャネル134を介して直に、の何れかで伝えられる。
3.セキュリティサーバ140は、トランザクションを復号し、真正性を検証しかつ次に、ユーザへのセキュリティウィンドウ110におけるトランザクションの表示を指令する。先に述べたように、トランザクション署名が要求されていれば、セキュリティサーバ140は、トランザクションOTPを計算し、かつそのトランザクションOTPのセキュリティウィンドウ110におけるユーザへの表示も指令する。
4.セキュリティサーバ140は、次に、暗号化されたtransaction_responseを準備し、最初の送信に応答してこれをブラウザ207またはウェブサイトアプリケーション212へ送り返し、ブラウザ207またはウェブサイトアプリケーション212は、次に暗号化されたtransaction_responseをウェブサイト130へ送信する。
5.ウェブサイト130は、次に、transaction_verify()APIを呼び出し、transaction_verify()APIは、結果をそのウェブサイトへ返す。
暗号鍵の管理
Upon joining the website 130, the security API 135 is advantageously implemented to perform the following functional steps.
1. The website 130 calls the transaction_request () API, and the transaction_request () API returns the encrypted transaction_request. In addition to the transaction itself (which may also simply be a transaction OTP request), the website 130 may either (i) simply display the transaction to the user, or (ii) the user clicks “OK” in the security window 110, Or indicate whether the user wishes to provide some corresponding indication to approve the transaction displayed in security window 110, or (iii) obtain a transaction signature.
2. The encrypted transaction is then routed directly to the security server 140 via the user's browser 207 or website application 212 or via a direct communication channel 134 between the security server 140 and website 130. In either case, it is transmitted.
3. Security server 140 decrypts the transaction, verifies authenticity, and then commands the user to display the transaction in security window 110. As described above, if a transaction signature is requested, the security server 140 calculates the transaction OTP and also instructs the user to display the transaction OTP in the security window 110.
4). The security server 140 then prepares an encrypted transaction_response and sends it back to the browser 207 or website application 212 in response to the initial transmission, which is then encrypted. The transaction_response is transmitted to the website 130.
5. The website 130 then calls transaction_verify () API, which returns the result to the website.
Encryption key management

2CHKシステムの要は、ユーザのコンピュータ装置100、例えばユーザのPCまたはスマートモバイル通信デバイス上のセキュリティウィンドウ120と、セキュリティサーバ140との間に安全な暗号化されかつ独立した通信チャネル144を確立することである。   The key to a 2CHK system is to establish a secure encrypted and independent communication channel 144 between the security server 120 and the security server 140 on the user's computer device 100, eg, the user's PC or smart mobile communication device. It is.

暗号鍵の生成は、次のようにして達成されてもよい。セキュリティウィンドウ120が起動された後の何らかの時点で、KMLC213または313は、秘密鍵/公開鍵ペア、例えばDu/Puを生成し、かつ秘密鍵Duを安全に(典型的には、メモリに)、例えばプライベートストレージ210aまたは312に格納する。KMLC213または313は、公開鍵Puをセキュリティサーバ140へ安全なチャネル144および妥当であればリンク320を介して送り、セキュリティサーバ140において、送信は、KMLS147によって傍受される。ユーザの公開鍵Puを含むデジタル証明書(「Cert」)は、KMLS147によって準備され、次の2つのうちの一方が発生する。   The generation of the encryption key may be achieved as follows. At some point after the security window 120 is activated, the KMLC 213 or 313 generates a private / public key pair, eg, Du / Pu, and securely (typically in memory) the private key Du. For example, it is stored in the private storage 210a or 312. The KMLC 213 or 313 sends the public key Pu to the security server 140 via the secure channel 144 and link 320 if appropriate, where the transmission is intercepted by the KMLS 147. A digital certificate ("Cert") containing the user's public key Pu is prepared by KMLS 147 and one of the following two is generated.

KMLS147が中間またはルート認証局として行動することができれば、これは、証明書に署名し、かつ署名された証明書をKMLC213または313へ返し、KMLC213または313は、これをプライベートストレージ210aまたは312等で局所的に(好ましくは、メモリに)保持する。例えば、KMLS147は、Certにその秘密/公開鍵ペアDs/Psのうちの秘密鍵Dsで署名することができ、よって、[Cert]DsがKMLC213または313へ安全なチャネル144および妥当であればリンク320を介して返される。   If KMLS 147 can act as an intermediate or root certificate authority, this will sign the certificate and return the signed certificate to KMLC 213 or 313, which will have it in private storage 210a or 312 etc. Maintain locally (preferably in memory). For example, KMLS 147 may sign Cert with private key Ds of its private / public key pair Ds / Ps, so [Cert] Ds is a secure channel 144 to KMLC 213 or 313 and a link if valid Returned via 320.

一方で、KMLS147が「登録局」として行動すれば、これは、通信チャネル148を介して外部の認証局170へ証明書要求を転送し、認証局170は、証明書を作成しかつこれを同じ通信チャネルを介してKMLS147へ返す。KMLS147は、次に、通信チャネル144を介して証明書をKMLC213または313へ転送し返し、KMLC213または313は、これを局所的に(好ましくは、メモリに)、例えばプライベートストレージ210aまたは312内に保持する。このような場合、Certは、認証局によりその秘密/公開鍵ペアDca/Pcaのうちの秘密鍵Dcaで署名され、よって[Cert]DcaがKMLS147へ返される。KMLS147は、次に、受信された署名入りCert、即ち[Cert]Dcaを安全なチャネル144を介して、および妥当であればリンク320を介してKMLC213または313へ転送する。   On the other hand, if KMLS 147 acts as a “registration authority”, it forwards the certificate request to external certificate authority 170 via communication channel 148, which creates the certificate and Return to KMLS 147 via communication channel. The KMLS 147 then forwards the certificate back to the KMLC 213 or 313 via the communication channel 144, and the KMLC 213 or 313 holds it locally (preferably in memory), for example in the private storage 210a or 312. To do. In such a case, the Cert is signed by the certificate authority with the private key Dca of the private / public key pair Dca / Pca, and thus [Cert] Dca is returned to the KMLS 147. The KMLS 147 then forwards the received signed Cert, ie [Cert] Dca, to the KMLC 213 or 313 via the secure channel 144 and, if appropriate, via the link 320.

何れの例においても、発行されるCertは、比較的短命、即ち一時的であって、2CHKセッション自体の寿命に一致することが好ましい。鍵の生成を起動と同時的にして単純化することにより、デジタル証明書および秘密鍵を局所的に長い期間に渡って格納する必要性が回避される。   In either example, the issued Cert is preferably relatively short-lived, i.e. temporary, and matches the lifetime of the 2CHK session itself. By simplifying key generation at the same time as activation, the need to store digital certificates and private keys locally over a long period is avoided.

状況によっては、後により詳しく論じるように、秘密鍵および証明書は、同じコンピュータ装置100上の他のアプリケーション、例えばブラウザ207または例えば文書プロセッサ218である非ブラウザアプリケーションによって必要とされてもよい。基本的なオペレーティングシステムが、MS Windows(商標)またはApple MacOS(商標)がそうであるように、標準的な鍵ストアをサポートしていれば、KMLC213または313に、鍵を鍵ストアへ格納しかつ適宜これらを削除するというタスクが課される可能性がある。   In some situations, as discussed in more detail later, the private key and certificate may be required by other applications on the same computing device 100, such as a browser 207 or a non-browser application such as a document processor 218. If the basic operating system supports a standard key store, as does MS Windows ™ or Apple MacOS ™, the KMLC 213 or 313 stores the key in the key store and There is a possibility that a task of deleting these may be imposed as appropriate.

公開鍵暗号化に適する上述の鍵、即ち非対称鍵の生成に加えて、鍵管理システムは、対称鍵も生成しかつ配分することができる。これの要は、KMLS147内に組み込まれる関数Shared_Secret_Generator()であり、これは、入力としてユーザID(おそらくは、ユーザの有線または携帯電話番号)、セキュリティサーバ140のみに知られる長寿命の秘密および他の種々雑多のパラメータ等のファクタを取り入れ、かつ出力としてshared_secret Kを生成する。所定の入力セットに関しては、同じ共有秘密が確定的に計算される点に留意することが重要である。KMLS147に対しては、認証された異なる存在が、KMLS147へ妥当な入力パラメータを提供することにより、妥当な対称鍵を提供するように要求することができる。   In addition to generating the above-described keys suitable for public key encryption, ie, asymmetric keys, the key management system can also generate and distribute symmetric keys. At the heart of this is the function Shared_Secret_Generator () that is built into KMLS 147, which has as input the user ID (probably the user's wired or mobile phone number), a long-lived secret known only to the security server 140 and other A factor such as various parameters is taken in and a shared_secret K is generated as an output. It is important to note that for a given input set, the same shared secret is deterministically calculated. For KMLS 147, different authenticated entities may request to provide a valid symmetric key by providing valid input parameters to KMLS 147.

アプリケーションに依存して、鍵管理ロジックは、上述の非対称(即ち、公開)鍵暗号化方式および対称鍵暗号化方式の機能の一方または双方を利用する場合があることに留意されたい。   Note that depending on the application, the key management logic may utilize one or both of the functions of the asymmetric (ie, public) and symmetric key encryption schemes described above.

以下、鍵管理を2CHKアーキテクチャの上へ層化し得る有益な方法について、幾つかの例を述べる。   The following describes some examples of useful ways in which key management can be layered on top of the 2CHK architecture.

第1の例は、デジタル署名に関する。デジタル署名を必要とするアプリケーションでは、ユーザは、秘密鍵およびデジタル証明書、即ちユーザの識別と認証局により証明された公開鍵との結び付きを提供される必要がある。セキュリティサーバを含むいかなる第三者にも知られていないこのような秘密鍵の使用は、ある種のアプリケーションに必要である強力な否認防止を提供する。以下、公開鍵暗号化方式で作成される産業協定署名を、「デジタル署名」と称する。当業者には理解されるように、かつ先に論じたように、先に述べたトランザクションOTP等の共有秘密を用いる基本的な対称暗号化方式に基づくトランザクション署名は、通常「電子署名」と称される。   The first example relates to a digital signature. In an application that requires a digital signature, the user needs to be provided with a private key and a digital certificate, ie a connection between the user's identity and a public key certified by a certificate authority. The use of such secret keys that are unknown to any third party, including security servers, provides the strong non-repudiation that is required for certain applications. Hereinafter, the industrial agreement signature created by the public key encryption method is referred to as “digital signature”. As understood by those skilled in the art and as discussed above, transaction signatures based on the basic symmetric encryption scheme using a shared secret such as the transaction OTP described above are usually referred to as “electronic signatures”. Is done.

別の例は、鍵の配布に関連する。   Another example relates to key distribution.

さらに別の例は、暗号化文書の配布に関連する。ユーザへ暗号化されたファイル、例えば証券取引明細書のPDFが送られると、ユーザは、ファイルの暗号化に使用された鍵を提供される必要がある。   Yet another example relates to the distribution of encrypted documents. When an encrypted file is sent to the user, for example a PDF of a securities statement, the user needs to be provided with the key used to encrypt the file.

これらの全ての例において、鍵管理は、システムのコスト高に直結し、かつ間接的にセキュリティに影響する。鍵の生成、配布および保持が、同時的に必要となる。鍵は、紛失、改竄または盗難の可能性があることから、鍵管理は通常、コストの重大な部分を占め、かつシステムの脆弱な点となる。   In all these examples, key management is directly linked to the high cost of the system and indirectly affects security. Key generation, distribution and retention are required simultaneously. Because keys can be lost, tampered with, or stolen, key management usually represents a significant part of the cost and is a weak point of the system.

鍵管理システムをその鍵生成機能を含めて記述したが、鍵管理機能の利用方法は、以下の3つのアプリケーション例によってさらに理解されるであろう。   Although the key management system has been described including its key generation function, the usage of the key management function will be further understood by the following three application examples.

第1の例は、デジタル署名のための2CHKシステムの使用に対処する。所定のアプリケーションでは、公開鍵暗号化方式を用いるデジタル署名が電子トランザクション署名より適切であるとされている。デジタル署名を達成するために、エンドユーザは、ブラウザ207またはウェブサイトアプリケーション212を用いて閲覧し、かつウェブサイト130とのトランザクションを実行する。ウェブサイト130は、KMLWS137を用いて、必要とされる「デジタル署名」によるトランザクション署名を要求する。この要求は、安全なバックエンド通信チャネル134上でKMLS147へ送られる。この要求は、次に、デジタル署名が必要とされていることの指示と共にKMLS147から安全なチャネル144、および妥当であればリンク320を介してKMLC213または313へ送られる。トランザクション署名、即ちトランザクションOTPは、場合により、セキュリティサーバ140によって生成され、かつデジタル署名要求と共に、セキュリティウィンドウ120に表示するために持続的で安全な通信チャネル144および妥当であればリンク320を介してセキュリティアプリケーション213または313へ送られ、次いで、ユーザのコンピュータ装置100、例えばユーザのPCまたはスマートフォン、他に表示される。   The first example addresses the use of a 2CHK system for digital signatures. In certain applications, digital signatures using public key cryptography are considered more appropriate than electronic transaction signatures. To accomplish the digital signature, the end user browses using browser 207 or website application 212 and performs a transaction with website 130. Website 130 uses KMLWS 137 to request a transaction signature with the required “digital signature”. This request is sent to the KMLS 147 over the secure backend communication channel 134. This request is then sent from the KMLS 147 to the KMLC 213 or 313 via the secure channel 144, and link 320 if appropriate, with an indication that a digital signature is required. A transaction signature, or transaction OTP, is optionally generated by the security server 140 and via a persistent secure communication channel 144 and link 320 if appropriate for display in the security window 120 with a digital signature request. Sent to the security application 213 or 313 and then displayed on the user's computer device 100, eg, the user's PC or smartphone, etc.

セキュリティウィンドウ120は、通常通りユーザにトランザクションを示し、かつ場合により、ユーザにトランザクションOTP、即ち電子署名を、ブラウザアプリケーション207またはウェブサイトアプリケーション212によって表示されるウィンドウ110へコピーするように要求する。並行して、KMLC213または313は、トランザクションのハッシュ(「HashTran」)を計算し、かつ先にメモリに格納されたユーザの秘密鍵Duを用いてデジタル署名を計算する。結果は、[HashTran]Duとなる。この処理は、舞台裏で、またはトランザクションへの署名に同意するようにユーザに求めることによって、発生する可能性もある。何れの場合も、秘密鍵Duは、ハッシュされたトランザクション[HashTran]へ適用される。デジタル署名されたトランザクションのハッシュ[HashTran]Duは、次に、安全な通信チャネル144および妥当であればリンク320を介してKMLC213または313からKMLS147へ、デジタル証明書[Cert]Dsまたは[Cert]Dcaと共に送られる。   The security window 120 shows the transaction to the user as usual and optionally requests the user to copy the transaction OTP, i.e. the electronic signature, to the window 110 displayed by the browser application 207 or the website application 212. In parallel, the KMLC 213 or 313 calculates a hash of the transaction (“HashTran”) and a digital signature using the user's private key Du previously stored in memory. The result is [HashTran] Du. This process may occur behind the scenes or by asking the user to agree to sign the transaction. In any case, the secret key Du is applied to the hashed transaction [HashTran]. The hash [HashTran] Du of the digitally signed transaction is then sent from the KMLC 213 or 313 to the KMLS 147 via the secure communication channel 144 and link 320 if appropriate to the digital certificate [Cert] Ds or [Cert] Dca. Sent with.

KMLS147は、場合により、ユーザの公開鍵Puをデジタル署名[HashTran]Duへ適用してHashTranを取得し、かつこれを独自に生成されたHashTranと比較することにより、署名の検証を遂行することができる。検証遂行の有無に関わらず、KMLS147は、署名、即ち[HashTran]Duおよび証明書、即ち[Cert]Dsまたは[Cert]Dcaを、安全なチャネル234を介してKMLAPI420へ転送する。   In some cases, the KMLS 147 may perform signature verification by applying the user's public key Pu to the digital signature [HashTran] Du to obtain a HashTran, and comparing it with the HashTran generated independently. it can. Regardless of whether verification is performed, KMLS 147 forwards the signature, ie [HashTran] Du, and the certificate, ie [Cert] Ds or [Cert] Dca, to KMAPI 420 via secure channel 234.

KMLWS137は、ハッシュHashTranを再計算し、かつデジタル証明書Certに含まれるユーザの公開鍵Puを用いて署名を検証することができる。したがって、KMLWS137は、KMLS147の公開鍵Psを[Cert]Dsへ適用し、または認証局公開鍵Pcaを[Cert]Dcaへ適用してPuを回復する。KMLWS137は、次に、回復されたPuを[HashTran]Duへ適用してHashTranを回復し、かつこれを独自に生成されたHashTranと比較して署名を検証する。   The KMLWS 137 can recalculate the hash HashTran and verify the signature using the user's public key Pu included in the digital certificate Cert. Therefore, the KMLWS 137 applies the public key Ps of the KMLS 147 to [Cert] Ds, or applies the certification authority public key Pca to the [Cert] Dca to recover Pu. KMLWS 137 then applies the recovered Pu to [HashTran] Du to recover HashTran and verifies the signature by comparing it to the independently generated HashTran.

上述の説明では、ハッシュがKMLC213または313において作成されることに留意されたい。これは、KMLWA137またはKMLS147においても同じく容易に作成される可能性もあるが、これらの存在は各々、その真正について確信を得るためにハッシュを再計算する可能性が高い。   Note that in the above description, the hash is created in KMLC 213 or 313. This could also be easily created in KMLWA 137 or KMLS 147, but each of these is likely to recalculate the hash to get confidence about its authenticity.

この例では、トランザクション全体がセキュリティウィンドウ120に至る。一方で、この手法を用いて文書に署名する必要があれば、KMLC213または313に秘密鍵および公開鍵をユーザのコンピュータ装置100上で利用可能な鍵ストアへ格納させるように、機能を拡張することが可能であり、これにより、鍵は、他のアプリケーション、例えばスマートフォンアプリを含むブラウザまたは非ブラウザアプリケーションで利用可能になる。KMLC213または313は、ユーザ鍵を適時鍵ストアから削除することを担当すると思われる。   In this example, the entire transaction reaches the security window 120. On the other hand, if it is necessary to sign a document using this technique, the function is extended so that the KMLC 213 or 313 stores the private key and the public key in a key store that can be used on the user's computer device 100. This allows the key to be used in other applications, such as browsers including smartphone apps or non-browser applications. The KMLC 213 or 313 may be responsible for deleting the user key from the key store in a timely manner.

第2の例では、2CHKシステムが鍵配布に使用される。eメールのように、データが格納および転送システムにおいて暗号化されかつ受信者へ転送されることは、頻繁に発生する。例えば、法規は、財務諸表または健康記録等の文書がeメールへの添付ファイルとして送信される場合、これらを必ず暗号化して送信することを求めている。多くのアプリケーション、例えばWinZip(商標)およびAcrobat Reader(商標)は、埋込みパスワードをベースとする暗号化機能を有する。すると、復号パスワードをどのようにしてユーザへ送信するか、に関して問題が生じる。1つの手法は、共有パスワードに対して事前に合意することである。この手法の欠点は、不正侵入されたパスワードを用いて多くの文書が復号される可能性があることにあるが、複雑なパスワードを要求することもまた、ユーザがパスワードを忘れる可能性が高いために困難である。以下、2CHK鍵管理を用いてこの問題点を解決する3手法について述べる。   In the second example, a 2CHK system is used for key distribution. Frequently, data is encrypted and transferred to a recipient in a storage and transfer system, such as email. For example, laws and regulations require that documents such as financial statements or health records be transmitted encrypted as attachments to emails. Many applications, such as WinZip ™ and Acrobat Reader ™, have embedded password-based encryption capabilities. This creates a problem as to how the decryption password is sent to the user. One approach is to agree on a shared password in advance. The disadvantage of this approach is that many documents can be decrypted using a compromised password, but requesting a complex password is also likely to cause the user to forget the password. It is difficult to. Hereinafter, three methods for solving this problem using 2CHK key management will be described.

第1の手法では、例えば一意のDocumentIDによって一意に識別された文書が、ウェブサイト130により、PIN、例えば英数字8文字のPINから導出される鍵を用いて暗号化され、次いで、例えばeメールを介してユーザへ送られる。この議論のの目的においては、DocumentIDは、送信者識別、受信者識別および文書識別の特定の組合せに関連づけられる一意の値である。ユーザが文書を何らかの非ブラウザアプリケーション218を用いて、典型的には、例えばWinZip(商標)およびAcrobat Reader(商標)であるそのPC上のソフトウェアアプリケーションを用いて開くと、プログラムは、ウェブサイト130へ、ユーザが特定の文書を読もうとしていることを示す信号を送る。アプリケーション218が、代わりにブラウザ207であることも可能ではあるが、本議論のの目的においては、これは、非ブラウザソフトウェアであることが想定されている。   In the first approach, a document uniquely identified by a unique DocumentID, for example, is encrypted by the website 130 using a key derived from a PIN, for example an 8-character PIN, and then e-mail, for example. Sent to the user. For the purposes of this discussion, DocumentID is a unique value associated with a particular combination of sender identification, recipient identification, and document identification. When a user opens a document using any non-browser application 218, typically using a software application on that PC, eg, WinZip ™ and Acrobat Reader ™, the program goes to the website 130. Send a signal indicating that the user is about to read a particular document. Application 218 could alternatively be browser 207, but for the purposes of this discussion it is assumed to be non-browser software.

ウェブサイト130は、DocumentIDにより参照された文書を最初に暗号化したPINを検索し、次いで、KMLWS137を用いてこのPINをセキュリティサーバ140へ通信リンク134を介して送る。セキュリティサーバ140は、KMLS147を用いてPINをKMLC213または313へ通信チャネル144および妥当であればリンク320を介して転送し、PINは、次に、セキュリティウィンドウ120内でユーザへ表示される。   The website 130 retrieves the PIN that originally encrypted the document referenced by the DocumentID, and then sends the PIN to the security server 140 via the communication link 134 using the KMLWS 137. Security server 140 uses KMLS 147 to forward the PIN to KMLC 213 or 313 via communication channel 144 and link 320 if appropriate, which is then displayed to the user within security window 120.

ユーザは、PINをアプリケーション218へコピーし、復号が通常通りに進行する。一般に、アプリケーション218の変更が要求されないことは注目されるべきである。開かれた時点でウェブサイト130へのメッセージをもたらす能力は、多くのアプリケーション(例えば、Adobe Reader)へ既に埋め込まれている機能である。   The user copies the PIN to application 218 and decryption proceeds as usual. It should be noted that in general, changes to application 218 are not required. The ability to bring a message to the website 130 when opened is a feature that is already embedded in many applications (eg, Adobe Reader).

上述の手法における1つの欠点は、ウェブサイト130がDocumentIDおよびPINのリストを保持しなければならないことにある。   One drawback to the above approach is that the website 130 must maintain a list of DocumentIDs and PINs.

この問題点を解決する一方法は、第2の手法を用い、かつ各文書の暗号化に用いる鍵を、DocumentIDおよびウェブサイト130にのみ知られる長期間の秘密を入力として取る関数の結果とすることである。この方法では、鍵は、第1の手法で説明したように、ユーザが文書を開こうとした後に動的に生成されることが可能である。   One method for solving this problem is to use the second method and use the key used for encrypting each document as a result of a function that takes as input a DocumentID and a long-term secret known only to the website 130. That is. In this method, the key can be generated dynamically after the user tries to open the document, as described in the first technique.

第2の手法の欠点は、文書が開かれるとウェブサイト130が利用可能であってオンラインになる、という想定が存在することにある。文書を生成して配布するある種のシステムは、バックエンドのバッチシステムであることから、この想定は、必ずしも適用可能でない場合がある。   The disadvantage of the second approach is that there is an assumption that when the document is opened, the website 130 is available and online. This assumption may not always be applicable because certain systems that generate and distribute documents are back-end batch systems.

第3の手法では、2CHK鍵管理の共有秘密生成機能を用いて、この問題点を次のように解決することができる。   In the third method, this problem can be solved as follows using the shared secret generation function of 2CHK key management.

ウェブサイト130は、セキュリティサーバ140へ、暗号化を望むDocumentIDを一度に一つずつ、またはより高い可能性としてバッチファイルで、の何れかで送る。この議論の目的においては、ファイルは、送信者IDおよび受信者ID等のエンベロープ情報を含むことが想定される。KMLS147は、上述のShared_Secret_Generator()を用いてDocumentID毎に暗号鍵を計算する。例えばあるDocumentIDに対して鍵K1、他のDocumentIDに対して鍵K2、さらに他のDocumentIDに対して鍵K3、他、である。これらの鍵は、次に、KMLS147によってウェブサイト130へ返される。ウェブサイト130は、次に、個々の文書を妥当な鍵で暗号化し、かつ暗号化された文書を例えばeメールを介して個々の妥当なユーザへ送る。   The website 130 sends to the security server 140 one of the DocumentIDs that it wishes to encrypt, one at a time, or more likely in a batch file. For purposes of this discussion, it is assumed that the file includes envelope information such as sender ID and receiver ID. The KMLS 147 calculates an encryption key for each DocumentID using the above-described Shared_Secret_Generator (). For example, the key K1 is for a certain DocumentID, the key K2 is for another DocumentID, and the key K3 is for another DocumentID. These keys are then returned to the website 130 by the KMLS 147. The website 130 then encrypts each individual document with a valid key and sends the encrypted document to each valid user via e-mail, for example.

妥当なユーザは、他のデスクトップソフトウェア218を用いて文書を開き、これにより、鍵要求が安全なウェブ接続(不図示)上で直接にセキュリティサーバ140へもたらされる。これが、セキュリティウィンドウ120を介さない非ブラウザアプリケーション218からセキュリティサーバ140への直接接続である点は留意されるべきである。   A valid user opens the document using other desktop software 218, which brings the key request directly to the security server 140 over a secure web connection (not shown). It should be noted that this is a direct connection from the non-browser application 218 to the security server 140 without going through the security window 120.

この動作により、KMLS147は、Shared_Secret_Generator()を用いて妥当な暗号鍵、例えばK1、K2、K3、他を再計算する結果となる。妥当な鍵は、次に、安全なチャネル144および妥当であればリンク320を介してKMLC213または313へ送られ、先に述べたように、非ブラウザアプリケーション218により表示されるウィンドウへコピーするためにセキュリティウィンドウ120内でユーザに表示される。   With this operation, the KMLS 147 results in recalculating appropriate encryption keys, for example, K1, K2, K3, etc., using Shared_Secret_Generator (). The valid key is then sent to the KMLC 213 or 313 via the secure channel 144 and link 320 if appropriate to copy it to the window displayed by the non-browser application 218 as described above. Displayed to the user within the security window 120.

上述の説明は、非ブラウザ・ソフトウェア・アプリケーション218(例えば、Acrobat Reader)を用いて行ったが、ブラウザをベースとするウェブアプリケーションでも同じ機能を使用することができる。
暗号鍵のシード付与
Although the above description has been made using a non-browser software application 218 (eg, Acrobat Reader), the same functionality can be used in a browser-based web application.
Cryptographic key seeding

ユーザがワンタイムパスワード生成ツールまたはトランザクション認証ツールの何れかのためにトークン認証ツールを提供されると、ユーザのトークンは、共有秘密鍵を提供される必要がある。当業者は、この意味合いにおいて、共有秘密鍵が「シード」として特徴づけられる場合が多いことを認識するであろう。OTPおよびトランザクション認証トークンの「シード付与」には、先に述べた2CHK鍵管理も使用されることが可能である。OTPおよびトランザクション認証トークン認証ツールは、全て、トークンに格納されかつバックエンドシステムにも格納される鍵を必要とする。これらの鍵(一般に、「シード」と称される)は、コストおよび複雑さをもたらす。2CHK鍵管理は、この手順を大幅に単純化するために使用されることが可能である。   When a user is provided with a token authentication tool for either a one-time password generation tool or a transaction authentication tool, the user's token needs to be provided with a shared secret key. Those skilled in the art will recognize that in this sense, a shared secret is often characterized as a “seed”. The 2CHK key management described above can also be used for “seeding” OTP and transaction authentication tokens. OTP and transaction authentication token authentication tools all require a key that is stored in the token and also stored in the backend system. These keys (commonly referred to as “seed”) introduce cost and complexity. 2CHK key management can be used to greatly simplify this procedure.

この議論の目的においては、トークン認証ツール(不図示)は、ハードウェア、ソフトウェアまたは携帯電話アプリとして実現されることが想定される。トークンは、シードが存在しない(または、シードのリフレッシュが要求される)不活性状態で始動する。要求は、ユーザによりセキュリティウィンドウ120内部から、またはトークンから直接、通信チャネル144を介してセキュリティサーバ140へ、またはシードの付与を要求する外部ウェブサイト130へ、の何れかで行われる。ユーザを識別する幾つかの一意の識別子は、適宜セキュリティサーバ140またはウェブサイト130へ提供される。   For the purposes of this discussion, it is assumed that the token authentication tool (not shown) is implemented as hardware, software or a mobile phone app. The token starts in an inactive state where there is no seed (or a seed refresh is required). The request is made by the user either from within the security window 120 or directly from the token, via the communication channel 144 to the security server 140 or to the external website 130 requesting seeding. Some unique identifiers identifying the user are provided to the security server 140 or website 130 as appropriate.

セキュリティサーバ140内部のKMLS147は、一意のUserID、およびKMLS147にのみ知られる長期間の秘密を含む他の情報を、Shared_Secret_Generator()への入力として使用し、そのユーザのための一意のシード(即ち、鍵)を生成する。例えば、起動時毎にシードを「シード付与」することは、ユーザの電話番号(または他のID)および2CHK事業者にのみ知られる秘密に基づいてシードを生成することを含む可能性がある。このようなシードは、起動毎に生成し直されるが、生成される度に同じ値を有する。しかしながら、幾分か修正されたアルゴリズムを用いることにより、起動毎に異なる値を有するシードを生成することも可能である。   The KMLS 147 within the security server 140 uses the unique UserID and other information including the long-term secret known only to the KMLS 147 as input to the Shared_Secret_Generator (), and a unique seed for that user (ie, Key). For example, “seeding” the seed at each startup may include generating the seed based on the user's phone number (or other ID) and a secret known only to the 2CHK operator. Such seeds are regenerated each time they are activated, but have the same value each time they are generated. However, it is also possible to generate seeds with different values for each activation by using a somewhat modified algorithm.

このシードは、安全なチャネル244および妥当であればリンク320を介してKMLC213または313へ送り返され、次に、セキュリティウィンドウ120においてユーザへ表示される。ユーザは、シードをソフトウェアまたはスマートフォンアプリのトークンへ入力する。実際のシードが、ユーザが入力するシードを変換する関数によって生成され得ることは、留意されるべきである。また、ハードウェアの場合、これは、トークンがキーパッドを有する場合に限って機能することも認識されるであろうが、実際に、大部分のトランザクション認証ツールはキーパッドを有する。   This seed is sent back to KMLC 213 or 313 via secure channel 244 and link 320 if appropriate, and then displayed to the user in security window 120. The user enters the seed into the token of the software or smartphone app. It should be noted that the actual seed can be generated by a function that transforms the seed entered by the user. It will also be appreciated that in the case of hardware, this will only work if the token has a keypad, but in practice most transaction authentication tools have a keypad.

上述の一変形例として、トランザクション認証ツールは、セキュリティアプリケーション210または310内へ機能の一部として直に組み込まれることが可能である点に注目されたい。一見して、この点の理論的根拠は明白ではないかもしれないが、EMV/CAP等の既存システムとの互換性は、この手法に理論的根拠を与える。トランザクション認証ツールのこのオンデマンドのシード付与は、付与のコストを大幅に単純化する。   It should be noted that as a variation of the above, the transaction authentication tool can be incorporated directly into the security application 210 or 310 as part of the functionality. At first glance, the rationale for this may not be obvious, but compatibility with existing systems such as EMV / CAP provides a rationale for this approach. This on-demand seeding of transaction authentication tools greatly simplifies the cost of granting.

先に述べたように、補助的ハードウェア上のセキュリティアプリ、即ち2CHKクライアント310も、OTPトークンを生成するために先に述べた技術を用いて「シード付与」されることが可能である。これは、補助的ハードウェアがもはやコンピュータ装置100へ接続されていない場合でも、これでOTPを補助的ハードウェア上で安全に生成できることを意味する。これまでは、コンピュータ装置100へ接続された補助的ハードウェア300によるシード付与関連動作について詳述したが、以下、コンピュータ装置100から外されている補助的ハードウェア300によってこれらの動作をどの程度確実に実行できるかについて述べる。この議論の目的においては、トークン認証ツール(不図示)は、ハードウェアとして、ソフトウェアとして、または補助的ハードウェアアプリとして実現されることが想定される。   As previously mentioned, the security app on the auxiliary hardware, ie the 2CHK client 310, can also be “seeded” using the techniques described above to generate the OTP token. This means that the OTP can now be safely generated on the auxiliary hardware even if the auxiliary hardware is no longer connected to the computing device 100. So far, the seeding-related operations by the auxiliary hardware 300 connected to the computer apparatus 100 have been described in detail. Hereinafter, how reliably these operations are performed by the auxiliary hardware 300 removed from the computer apparatus 100. The following describes what can be done. For the purposes of this discussion, it is assumed that the token authentication tool (not shown) is implemented as hardware, software, or as an auxiliary hardware application.

トークンは、シードが存在しない(または、シードのリフレッシュが要求される)不活性状態で始動する。補助的ハードウェア300がコンピュータ装置100から外された後、コンピュータ装置100へ接続された補助的ハードウェア300によって受信されて格納されたシードは、望ましい場合には、セキュリティアプリ、即ち2CHKクライアント310により、補助的ハードウェア300の画面302に表示されるセキュリティウィンドウ120においてユーザに示されることが可能である。ユーザは、次に、シードを補助的ハードウェア300のCPU305によって実行されるトークン生成ツール(不図示)に入力することができる。この場合もやはり、実際のシードは、ユーザが入力するシードを変換する関数によって生成されてもよいことに留意する。また、ハードウェアトークン生成ツールの場合、これは、トークン生成ツールがキーパッドを有する場合に限って機能することも認識されるであろうが、実際に、大部分のトランザクション生成ツールはキーパッドを有する。   The token starts in an inactive state where there is no seed (or a seed refresh is required). After the auxiliary hardware 300 is removed from the computer device 100, the seed received and stored by the auxiliary hardware 300 connected to the computer device 100 is, if desired, by the security app, ie, the 2CHK client 310. It can be shown to the user in a security window 120 displayed on the screen 302 of the auxiliary hardware 300. The user can then enter the seed into a token generation tool (not shown) that is executed by the CPU 305 of the auxiliary hardware 300. Again, note that the actual seed may be generated by a function that transforms the seed entered by the user. It will also be recognized that in the case of hardware token generation tools, this will only work if the token generation tool has a keypad, but in practice most transaction generation tools will have a keypad. Have.

先に述べたように、OTPの「シード付与」は、各起動時、即ち始動および起動ステージの間のシードを用いて実行される。具体的には、シード、即ち鍵は、ユーザの電話番号または他のユーザ識別子、およびセキュリティサーバ140にのみ知られる秘密に基づいて生成される。このシードは、起動時毎に生成し直されるが、同じ値を有することになる。   As mentioned above, OTP “seeding” is performed at each start-up, ie, using a seed between the start-up and start-up stages. Specifically, the seed, or key, is generated based on the user's telephone number or other user identifier and a secret known only to the security server 140. This seed is regenerated every time it is started, but has the same value.

ある代替手法は、最初の関連付けにおいて、即ちセットアップおよび個性化段階の間にシードを生成し、かつこのシードを局所的かつ持続的に、全体として又は部分的に、格納することである。したがって、この代替手法では、シードは、新規起動毎に、再生成される必要がなく、その全体が再生成される必要もない。この手法の主たる利点は、攻撃者が自動転送または他の何らかの機構を用いてユーザの電話番号を盗み、かつ新規に起動しても、攻撃者がシードを知ることにはならない点にある。したがって、このシードを用いてトランザクションOTPが生成されても、このシードを有していない攻撃者は阻止されることとなる。   One alternative approach is to generate a seed in the initial association, ie during the setup and personalization phase, and store this seed locally and persistently, in whole or in part. Thus, in this alternative approach, the seed does not need to be regenerated for every new launch, nor does it need to be regenerated in its entirety. The main advantage of this approach is that if an attacker steals a user's phone number using automatic forwarding or some other mechanism and starts a new one, the attacker will not know the seed. Therefore, even if a transaction OTP is generated using this seed, an attacker who does not have this seed is prevented.

Claims (6)

  1. ネットワークを介してのユーザと企業との間の商取引を安全に処理するようにセキュリティサーバを動作させる方法であって、
    前記セキュリティサーバにおいて、ユーザ・ネットワーク・デバイスから前記ネットワークを介して、前記ネットワーク上で前記ユーザ・ネットワーク・デバイスと前記セキュリティサーバとの間に安全な通信チャネルを起動するという前記ユーザの要求を受信することと、
    前記セキュリティサーバにより、前記受信された起動要求に応答して、他のネットワークを介して前記ユーザに配信するために起動コードを、送信することと、
    前記セキュリティサーバにおいて、前記ユーザ・ネットワーク・デバイスから前記ネットワークを介して起動コードを受信することと、
    前記セキュリティサーバにおいて、前記受信された起動コードを前記送信された起動コードと比較して、前記受信された起動コードを検証することと、
    前記受信された起動コードの前記検証に基づいて前記安全な通信チャネルを起動することと、
    セキュリティサーバにおいて、前記企業を代表するネットワークサーバから前記ネットワークを介して、質問の正解が、前記ユーザと前記企業とによって事前に合意されている前記ユーザへの質問を含む問い合わせを受信することと
    前記セキュリティサーバから、前記ユーザ・ネットワーク・デバイスへ前記安全な通信チャネルを介して、前記受信された企業側の問い合わせを送信することと、
    セキュリティサーバにおいて、前記ユーザ・ネットワーク・デバイスから前記安全な通信チャネルを介して、前記送信された企業側の問い合わせに対するユーザの回答を受信することと、
    前記ユーザを前記企業に対してさらに認証するために、前記セキュリティサーバから前記企業のネットワークサーバへ前記ネットワークを介して、前記受信されたユーザの回答を、当該回答が正答であるか否かを判定することなく送信することと、を含む方法。
    A method of operating a security server to securely process business transactions between a user and a company over a network,
    In the security server, via the network from the user network device receives a request of the user that activates the secure communication channel between the user network device and the security server over the network And
    Sending an activation code for delivery to the user via another network in response to the received activation request by the security server;
    Receiving an activation code from the user network device via the network in the security server;
    In the security server, comparing the received activation code with the transmitted activation code, and verifying the received activation code;
    Activating the secure communication channel based on the verification of the received activation code;
    The security server, via the network from a network server representing the company, and the correct answer questions receives an inquiry including the question to the user which has been agreed in advance by the said and the user enterprise,
    Sending the received corporate inquiry from the security server to the user network device via the secure communication channel;
    In the security server, receiving a user's answer to the transmitted corporate inquiry from the user network device via the secure communication channel;
    In order to further authenticate the user to the company, the security server determines whether the received answer is a correct answer from the security server to the company network server via the network. Without transmitting.
  2. 前記他のネットワークは、帯域外認証である、請求項1に記載の方法。   The method of claim 1, wherein the other network is out-of-band authentication.
  3. 前記帯域外認証ネットワークは、電話網である、請求項2に記載の方法。   The method of claim 2, wherein the out-of-band authentication network is a telephone network.
  4. 前記企業側の問い合わせは、前記ユーザと前記企業とに共有される秘密、および前記ユーザの個人的な情報のうちの1つについて尋ねる、請求項1に記載の方法。   The method of claim 1, wherein the company inquiry asks for one of a secret shared between the user and the company, and personal information of the user.
  5. 前記セキュリティサーバにおいて、前記受信された企業側の問い合わせを音声ストリームおよび画像の少なくとも一方へ組み込むことをさらに含み、
    前記送信された企業側の問い合わせは、前記音声ストリームおよび前記画像の前記少なくとも一方へ組み込まれた前記企業側の問い合わせである、請求項1に記載の方法。
    Further comprising, in the security server, incorporating the received corporate inquiry into at least one of an audio stream and an image;
    The method of claim 1, wherein the transmitted enterprise inquiry is an enterprise inquiry embedded in the audio stream and / or the image.
  6. 前記音声ストリームは、前記ユーザが認識できる音声を有する音声ストリームであり、かつ前記画像は、前記ユーザが知る背景を有する画像である、請求項に記載の方法。 The method according to claim 5 , wherein the audio stream is an audio stream having audio that can be recognized by the user, and the image is an image having a background known to the user.
JP2015516019A 2012-06-07 2013-05-06 Enhanced 2CHK authentication security through inquiry-type transactions Active JP6012125B2 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
US13/490,715 2012-06-07
US13/490,715 US9716691B2 (en) 2012-06-07 2012-06-07 Enhanced 2CHK authentication security with query transactions
PCT/US2013/039684 WO2013184267A1 (en) 2012-06-07 2013-05-06 Enhanced 2chk authentication security with query transactions

Publications (2)

Publication Number Publication Date
JP2015526784A JP2015526784A (ja) 2015-09-10
JP6012125B2 true JP6012125B2 (ja) 2016-10-25

Family

ID=49712452

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2015516019A Active JP6012125B2 (ja) 2012-06-07 2013-05-06 Enhanced 2CHK authentication security through inquiry-type transactions

Country Status (10)

Country Link
US (2) US9716691B2 (ja)
EP (1) EP2859489B1 (ja)
JP (1) JP6012125B2 (ja)
AU (1) AU2013272184B2 (ja)
CA (1) CA2875563A1 (ja)
DE (1) DE13801298T1 (ja)
ES (1) ES2553222T3 (ja)
HK (1) HK1207714A1 (ja)
SG (1) SG11201408025SA (ja)
WO (2) WO2013184267A1 (ja)

Families Citing this family (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9578664B1 (en) 2013-02-07 2017-02-21 Sprint Communications Company L.P. Trusted signaling in 3GPP interfaces in a network function virtualization wireless communication system
ES2754198T3 (es) * 2013-06-24 2020-04-16 Telefonica Digital Espana Slu A computer-implemented method of improving security in authentication / authorization systems and their software products
US9355235B1 (en) * 2013-12-06 2016-05-31 Emc Corporation Validating a user of a virtual machine for administrator/root access
US20160316311A1 (en) * 2013-12-13 2016-10-27 Nokia Technologies Oy Method and apparatus for provisioning an operational subscription
US9710640B1 (en) 2014-03-28 2017-07-18 Amazon Technologies, Inc. Bootstrapping authentication of second application via confirmation by first application
US9602501B1 (en) 2014-03-28 2017-03-21 Amazon Technologies, Inc. Bootstrapping user authentication
US9380057B2 (en) * 2014-07-29 2016-06-28 Lexisnexis Risk Solutions Inc. Systems and methods for combined OTP and KBA identity authentication
US10375063B2 (en) 2014-07-29 2019-08-06 Lexisnexis Risk Solutions Inc. Systems and methods for combined OTP and KBA identity authentication utilizing academic publication data
CN105450620B (zh) 2014-09-30 2019-07-12 阿里巴巴集团控股有限公司 一种信息处理方法及装置
US10757216B1 (en) 2015-02-20 2020-08-25 Amazon Technologies, Inc. Group profiles for group item recommendations
CN106200891B (zh) * 2015-05-08 2019-09-06 阿里巴巴集团控股有限公司 显示用户界面的方法、装置及系统
US9686240B1 (en) 2015-07-07 2017-06-20 Sprint Communications Company L.P. IPv6 to IPv4 data packet migration in a trusted security zone
CN106447323A (zh) 2015-08-05 2017-02-22 阿里巴巴集团控股有限公司 业务验证方法及装置
US9749294B1 (en) 2015-09-08 2017-08-29 Sprint Communications Company L.P. System and method of establishing trusted operability between networks in a network functions virtualization environment
KR101715504B1 (ko) * 2015-09-16 2017-03-14 성균관대학교산학협력단 색상 코드를 이용하여 otp 인증을 수행하는 방법 및 색상 코드를 이용하는 otp 인증 서버
US10542115B1 (en) 2015-10-01 2020-01-21 Sprint Communications Company L.P. Securing communications in a network function virtualization (NFV) core network
US9811686B1 (en) * 2015-10-09 2017-11-07 Sprint Communications Company L.P. Support systems interactions with virtual network functions in a trusted security zone
US9781016B1 (en) 2015-11-02 2017-10-03 Sprint Communications Company L.P. Dynamic addition of network function services
US10091193B2 (en) * 2015-12-30 2018-10-02 Mastercard International Incorporated One time passcode
US20170257363A1 (en) * 2016-03-04 2017-09-07 Secureauth Corporation Secure mobile device two-factor authentication
US10521572B2 (en) 2016-08-16 2019-12-31 Lexisnexis Risk Solutions Inc. Systems and methods for improving KBA identity authentication questions
US10567387B1 (en) * 2016-09-13 2020-02-18 Symantec Corporation Systems and methods for managing computing device access to local area computer networks
US10250498B1 (en) 2016-10-03 2019-04-02 Sprint Communications Company L.P. Session aggregator brokering of data stream communication
US10348488B1 (en) 2017-08-25 2019-07-09 Sprint Communications Company L.P. Tiered distributed ledger technology (DLT) in a network function virtualization (NFV) core network

Family Cites Families (106)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5736932A (en) * 1996-07-03 1998-04-07 At&T Corp Security for controlled access systems
JPH11338933A (ja) 1998-05-21 1999-12-10 Micro Cabin:Kk 通信取引における取引申込者の認証システム
IL128720A (en) 1999-02-25 2009-06-15 Cidway Technologies Ltd Method for certification of over the phone transactions
US6671672B1 (en) * 1999-03-30 2003-12-30 Nuance Communications Voice authentication system having cognitive recall mechanism for password verification
US6999943B1 (en) 2000-03-10 2006-02-14 Doublecredit.Com, Inc. Routing methods and systems for increasing payment transaction volume and profitability
AU6661401A (en) 2000-05-25 2001-12-03 Echarge Corp Secure transaction protocol
US20040030934A1 (en) 2001-10-19 2004-02-12 Fumio Mizoguchi User selectable authentication interface and universal password oracle
CN1394312A (zh) * 2000-11-10 2003-01-29 株式会社Ntt都科摩 鉴别系统、鉴别承担装置和终端装置
US6983381B2 (en) 2001-01-17 2006-01-03 Arcot Systems, Inc. Methods for pre-authentication of users using one-time passwords
JP2002259344A (ja) 2001-02-28 2002-09-13 Mitsubishi Electric Corp ワンタイムパスワード認証システム及び携帯電話及びユーザ認証サーバ
WO2003014867A2 (en) 2001-08-03 2003-02-20 John Allen Ananian Personalized interactive digital catalog profiling
US7493259B2 (en) * 2002-01-04 2009-02-17 Siebel Systems, Inc. Method for accessing data via voice
US20040010698A1 (en) * 2002-05-30 2004-01-15 Rolfe Andrew R. Digital certificate system incorporating voice biometric processing
US7370194B2 (en) * 2002-06-10 2008-05-06 Microsoft Corporation Security gateway for online console-based gaming
US20040210536A1 (en) 2002-12-18 2004-10-21 Tino Gudelj Cross-domain transactions through simulated pop-ups
SI21436A (sl) * 2003-02-04 2004-08-31 Renderspace - Pristop Interactive D.O.O. Sistem identifikacije za vstop v varovano področje
US8023958B2 (en) 2003-03-05 2011-09-20 Qualcomm Incorporated User plane-based location services (LCS) system, method and apparatus
US7421732B2 (en) 2003-05-05 2008-09-02 Nokia Corporation System, apparatus, and method for providing generic internet protocol authentication
US8572391B2 (en) 2003-09-12 2013-10-29 Emc Corporation System and method for risk based authentication
FR2861236B1 (fr) * 2003-10-21 2006-02-03 Cprm Procede et dispositif d'authentification dans un reseau de telecommunication utilisant un equipement portable
TW200522598A (en) 2003-12-19 2005-07-01 Iwics Inc Data transport protocol for a multi-station network
US7546357B2 (en) * 2004-01-07 2009-06-09 Microsoft Corporation Configuring network settings using portable storage media
JP2005209083A (ja) 2004-01-26 2005-08-04 Japan Telecom Co Ltd サービスシステム、及びそれを用いた通信システム、通信方法
US20050172229A1 (en) 2004-01-29 2005-08-04 Arcot Systems, Inc. Browser user-interface security application
US20050254653A1 (en) 2004-05-14 2005-11-17 Proxim Corporation Pre-authentication of mobile clients by sharing a master key among secured authenticators
US8296562B2 (en) 2004-07-15 2012-10-23 Anakam, Inc. Out of band system and method for authentication
FI20050022A0 (fi) * 2005-01-10 2005-01-10 Nokia Corp Verkkoon pääsyn valvonta
US20060168259A1 (en) 2005-01-27 2006-07-27 Iknowware, Lp System and method for accessing data via Internet, wireless PDA, smartphone, text to voice and voice to text
US20060235795A1 (en) 2005-04-19 2006-10-19 Microsoft Corporation Secure network commercial transactions
US7386105B2 (en) * 2005-05-27 2008-06-10 Nice Systems Ltd Method and apparatus for fraud detection
US7734912B2 (en) * 2005-05-31 2010-06-08 Tricipher, Inc. Secure login using single factor split key asymmetric cryptography and an augmenting factor
US7743409B2 (en) 2005-07-08 2010-06-22 Sandisk Corporation Methods used in a mass storage device with automated credentials loading
JP4861417B2 (ja) 2005-08-11 2012-01-25 サンディスク アイエル リミテッド 拡張ワンタイム・パスワード方法および装置
GB0519842D0 (en) 2005-09-29 2005-11-09 Hewlett Packard Development Co Methods and apparatus for managing and using one-time pads
JP2007102778A (ja) 2005-10-04 2007-04-19 Forval Technology Inc ユーザ認証システムおよびその方法
US8447700B2 (en) * 2005-10-11 2013-05-21 Amazon Technologies, Inc. Transaction authorization service
US20070283273A1 (en) 2005-10-24 2007-12-06 Woods Michael E System, Method, and Computer Program Product for Internet Tool
US8620989B2 (en) 2005-12-01 2013-12-31 Firestar Software, Inc. System and method for exchanging information among exchange applications
WO2007066542A1 (ja) 2005-12-09 2007-06-14 Hitachi Software Engineering, Co., Ltd. 認証システム及び認証方法
US9768963B2 (en) * 2005-12-09 2017-09-19 Citicorp Credit Services, Inc. (Usa) Methods and systems for secure user authentication
US20070157304A1 (en) 2006-01-05 2007-07-05 International Business Machines Corporation Method, apparatus and computer program product for automatic cookie synchronization between distinct web browsers
KR20070077569A (ko) 2006-01-24 2007-07-27 삼성전자주식회사 휴대폰을 이용한 일회용 패스워드 서비스 시스템 및 방법
US9137012B2 (en) 2006-02-03 2015-09-15 Emc Corporation Wireless authentication methods and apparatus
DK1987627T3 (en) 2006-02-03 2017-02-20 Mideye Ab A system, device and procedure for end-user authentication
US8234696B2 (en) 2006-02-10 2012-07-31 Emc Corporation Method and system for providing a one time password to work in conjunction with a browser
WO2007107868A2 (en) 2006-03-22 2007-09-27 Axalto Sa A method of securely login to remote servers
US7552467B2 (en) 2006-04-24 2009-06-23 Jeffrey Dean Lindsay Security systems for protecting an asset
JP2007310678A (ja) 2006-05-18 2007-11-29 Nippon Telegr & Teleph Corp <Ntt> アリバイ証明システム及び方法及びアリバイサーバ及びプログラム
JP4719717B2 (ja) * 2006-06-27 2011-07-06 株式会社リコー 画像処理装置、画像処理方法及び画像処理プログラム
US20080034216A1 (en) 2006-08-03 2008-02-07 Eric Chun Wah Law Mutual authentication and secure channel establishment between two parties using consecutive one-time passwords
US20080052245A1 (en) 2006-08-23 2008-02-28 Richard Love Advanced multi-factor authentication methods
US7818216B2 (en) 2006-08-28 2010-10-19 Seraphim Lawhorn Transaction system with centralized data storage and authentication
US8424061B2 (en) * 2006-09-12 2013-04-16 International Business Machines Corporation Method, system and program product for authenticating a user seeking to perform an electronic service request
KR100786551B1 (ko) 2006-09-15 2007-12-21 이니텍(주) 복수 개의 방식에 의한 일회용 비밀번호의 사용자 등록,인증 방법 및 그러한 방법을 수행하는 프로그램이 기록된컴퓨터 판독 가능 기록 매체
US8112817B2 (en) 2006-10-30 2012-02-07 Girish Chiruvolu User-centric authentication system and method
US8060916B2 (en) 2006-11-06 2011-11-15 Symantec Corporation System and method for website authentication using a shared secret
US20080120707A1 (en) 2006-11-22 2008-05-22 Alexander Ramia Systems and methods for authenticating a device by a centralized data server
US8151326B2 (en) 2006-12-08 2012-04-03 Core Mobility, Inc. Using audio in N-factor authentication
US8468244B2 (en) 2007-01-05 2013-06-18 Digital Doors, Inc. Digital information infrastructure and method for security designated data and with granular data stores
US8332921B2 (en) 2007-01-12 2012-12-11 Wmware, Inc. Enhanced security for user instructions
US7921221B2 (en) * 2007-01-22 2011-04-05 Minborg Invent I Goteborg Ab Method and apparatus for obtaining digital objects in a communication network
JP2010518515A (ja) * 2007-02-05 2010-05-27 ヴィドゥップ・エルエルシー 後援された帯域外パスワードの配信方法およびシステム
JP4648420B2 (ja) 2007-03-12 2011-03-09 ヤフー株式会社 認証システム
IL190839D0 (en) 2007-04-15 2008-12-29 Ari Eliaz Method and system for monetary billing for the use of content services in internet sites, by sending sms messages from cellular phones
US8078515B2 (en) 2007-05-04 2011-12-13 Michael Sasha John Systems and methods for facilitating electronic transactions and deterring fraud
US8056118B2 (en) * 2007-06-01 2011-11-08 Piliouras Teresa C Systems and methods for universal enhanced log-in, identity document verification, and dedicated survey participation
WO2009039223A1 (en) * 2007-09-17 2009-03-26 Vidoop Llc Methods and systems for management of image-based password accounts
GB0718817D0 (en) 2007-09-26 2007-11-07 British Telecomm Password management
US20090093300A1 (en) 2007-10-05 2009-04-09 Lutnick Howard W Game of chance processing apparatus
US8032939B2 (en) 2007-11-06 2011-10-04 Airtight Networks, Inc. Method and system for providing wireless vulnerability management for local area computer networks
WO2009070430A2 (en) 2007-11-08 2009-06-04 Suridx, Inc. Apparatus and methods for providing scalable, dynamic, individualized credential services using mobile telephones
JP2009169476A (ja) * 2008-01-10 2009-07-30 Nippon Telegr & Teleph Corp <Ntt> 認証方法、認証システム、認証装置、プログラム
US8255971B1 (en) * 2008-03-03 2012-08-28 Jpmorgan Chase Bank, N.A. Authentication system and method
US8302167B2 (en) 2008-03-11 2012-10-30 Vasco Data Security, Inc. Strong authentication token generating one-time passwords and signatures upon server credential verification
US8024576B2 (en) 2008-03-31 2011-09-20 International Business Machines Corporation Method and system for authenticating users with a one time password using an image reader
CA2632793A1 (en) 2008-04-01 2009-10-01 Allone Health Group, Inc. Information server and mobile delivery system and method
US8136148B1 (en) 2008-04-09 2012-03-13 Bank Of America Corporation Reusable authentication experience tool
US8272038B2 (en) 2008-05-19 2012-09-18 International Business Machines Corporation Method and apparatus for secure authorization
US8528045B2 (en) 2008-07-22 2013-09-03 Next Access Technologies, Llc Methods and systems for secure key entry via communication networks
US20100041391A1 (en) 2008-08-12 2010-02-18 Anthony Wayne Spivey Embedded mobile analytics in a mobile device
US8214890B2 (en) * 2008-08-27 2012-07-03 Microsoft Corporation Login authentication using a trusted device
US8245030B2 (en) 2008-12-19 2012-08-14 Nai-Yu Pai Method for authenticating online transactions using a browser
US20120005483A1 (en) 2009-04-09 2012-01-05 Hydrabyte, Inc. Method for Image-Based Authentication
US8230231B2 (en) 2009-04-14 2012-07-24 Microsoft Corporation One time password key ring for mobile computing device
US20100268831A1 (en) 2009-04-16 2010-10-21 Microsoft Corporation Thin Client Session Management
US8661258B2 (en) * 2009-10-23 2014-02-25 Vasco Data Security, Inc. Compact security device with transaction risk level approval capability
US8549601B2 (en) 2009-11-02 2013-10-01 Authentify Inc. Method for secure user and site authentication
US8769784B2 (en) 2009-11-02 2014-07-08 Authentify, Inc. Secure and efficient authentication using plug-in hardware compatible with desktops, laptops and/or smart mobile communication devices such as iPhones
US8458774B2 (en) * 2009-11-02 2013-06-04 Authentify Inc. Method for secure site and user authentication
US10049356B2 (en) 2009-12-18 2018-08-14 First Data Corporation Authentication of card-not-present transactions
US9021507B2 (en) 2009-12-29 2015-04-28 International Business Machines Corporation Dynamic use of data across multiple programs
US20110208801A1 (en) 2010-02-19 2011-08-25 Nokia Corporation Method and apparatus for suggesting alternate actions to access service content
JP2011238036A (ja) * 2010-05-11 2011-11-24 Ikutoku Gakuen 認証システム、シングルサインオンシステム、サーバ装置およびプログラム
US8745699B2 (en) 2010-05-14 2014-06-03 Authentify Inc. Flexible quasi out of band authentication architecture
US9350708B2 (en) * 2010-06-01 2016-05-24 Good Technology Corporation System and method for providing secured access to services
KR101683292B1 (ko) * 2010-06-18 2016-12-07 삼성전자주식회사 Pn 라우팅 테이블을 이용한 개인 네트워크의 구성 장치 및 방법
US9883387B2 (en) * 2011-03-24 2018-01-30 Visa International Service Association Authentication using application authentication element
US8713325B2 (en) * 2011-04-19 2014-04-29 Authentify Inc. Key management using quasi out of band authentication architecture
US8656465B1 (en) * 2011-05-09 2014-02-18 Google Inc. Userspace permissions service
US8595808B2 (en) * 2011-12-16 2013-11-26 Daon Holdings Limited Methods and systems for increasing the security of network-based transactions
US8959619B2 (en) * 2011-12-21 2015-02-17 Fleet One, Llc. Graphical image password authentication method
US8898766B2 (en) * 2012-04-10 2014-11-25 Spotify Ab Systems and methods for controlling a local application through a web page
US20140295956A1 (en) * 2012-05-23 2014-10-02 Cams, Llc Central account management system for user profiling
US10025920B2 (en) * 2012-06-07 2018-07-17 Early Warning Services, Llc Enterprise triggered 2CHK association
US8863260B2 (en) * 2012-06-07 2014-10-14 International Business Machines Corporation Enhancing password protection
US9741085B2 (en) * 2013-03-14 2017-08-22 Artificial Intelligence Research Group Limited System and method of encoding content and an image

Also Published As

Publication number Publication date
WO2013184267A1 (en) 2013-12-12
CA2875563A1 (en) 2013-12-12
AU2013272184B2 (en) 2018-05-24
DE13801298T1 (de) 2015-12-17
US20140041000A1 (en) 2014-02-06
ES2553222T1 (es) 2015-12-07
HK1207714A1 (en) 2016-02-05
JP2015526784A (ja) 2015-09-10
US10033701B2 (en) 2018-07-24
EP2859489A1 (en) 2015-04-15
EP2859489A4 (en) 2016-01-13
AU2013272184A1 (en) 2015-01-15
WO2013184266A2 (en) 2013-12-12
ES2553222T3 (es) 2020-04-15
EP2859489B1 (en) 2019-08-14
SG11201408025SA (en) 2015-01-29
US9716691B2 (en) 2017-07-25
US20130333008A1 (en) 2013-12-12

Similar Documents

Publication Publication Date Title
US10187211B2 (en) Verification of password using a keyboard with a secure password entry mode
US20180144114A1 (en) Securing Blockchain Transactions Against Cyberattacks
US9900163B2 (en) Facilitating secure online transactions
DE102017000768A1 (de) Verfahren zum Durchführen einer Zweifaktorauthentifizierung
US9130931B2 (en) Method for reading an attribute from an ID token
US9871791B2 (en) Multi factor user authentication on multiple devices
KR101878149B1 (ko) 패스워드의 보안 입력 및 처리 장치, 시스템 및 방법
US10136315B2 (en) Password-less authentication system, method and device
US9166971B1 (en) Authentication using an external device
US9313201B2 (en) System and method of performing electronic transactions
US9741033B2 (en) System and method for point of sale payment data credentials management using out-of-band authentication
JP6021923B2 (ja) Secure authentication method and system for online transactions
US8893237B2 (en) Secure and efficient login and transaction authentication using iphones# and other smart mobile communication devices
US8719952B1 (en) Systems and methods using passwords for secure storage of private keys on mobile devices
US8739260B1 (en) Systems and methods for authentication via mobile communication device
AU2011205391B2 (en) Anytime validation for verification tokens
US9112842B1 (en) Secure authentication and transaction system and method
US20160063491A1 (en) Secure online transactions using a trusted digital identity
US9191375B2 (en) System and method for accessing integrated applications in a single sign-on enabled enterprise solution
CA2689847C (en) Network transaction verification and authentication
US9197406B2 (en) Key management using quasi out of band authentication architecture
US9191394B2 (en) Protecting user credentials from a computing device
US9537861B2 (en) Method of mutual verification between a client and a server
US8468582B2 (en) Method and system for securing electronic transactions
US8245030B2 (en) Method for authenticating online transactions using a browser

Legal Events

Date Code Title Description
RD01 Notification of change of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7426

Effective date: 20141209

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A821

Effective date: 20141209

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20150206

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20160118

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20160217

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20160514

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20160514

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20160704

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20160902

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20160918

R150 Certificate of patent or registration of utility model

Ref document number: 6012125

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250