WO2010066127A1 - 基于应用层的移动金融业务的安全通信方法及其装置 - Google Patents

基于应用层的移动金融业务的安全通信方法及其装置 Download PDF

Info

Publication number
WO2010066127A1
WO2010066127A1 PCT/CN2009/072386 CN2009072386W WO2010066127A1 WO 2010066127 A1 WO2010066127 A1 WO 2010066127A1 CN 2009072386 W CN2009072386 W CN 2009072386W WO 2010066127 A1 WO2010066127 A1 WO 2010066127A1
Authority
WO
WIPO (PCT)
Prior art keywords
key
transaction
req
res
server
Prior art date
Application number
PCT/CN2009/072386
Other languages
English (en)
French (fr)
Inventor
李大科
赵金吉
林欣
皇海辉
Original Assignee
阿尔卡特朗讯
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 阿尔卡特朗讯 filed Critical 阿尔卡特朗讯
Priority to CN200980136629.6A priority Critical patent/CN102239714B/zh
Priority to US13/139,773 priority patent/US20110320359A1/en
Publication of WO2010066127A1 publication Critical patent/WO2010066127A1/zh

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/12Applying verification of the received information
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/382Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3829Payment protocols; Details thereof insuring higher security of transaction involving key management
    • 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
    • H04L63/0428Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0442Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply asymmetric encryption, i.e. different keys for encryption and decryption

Definitions

  • the present invention relates to secure communications, and more particularly to an application layer based secure communication method and apparatus in mobile communications. Background technique
  • TLS Transport Layer Security
  • WTLS Wireless Transport Layer Security
  • SET Secure Electronic Transaction
  • the protocol is too complicated. For example, there are too many round-trip messages between the two parties in the SET.
  • the processing performance of the two-party device has high requirements, making the protocol difficult to implement in a mobile phone or other mobile terminal with weak performance;
  • the application layer security protocol should have the following features:
  • the ability to secure all transactions in the mobile financial business ie to ensure the confidentiality, authenticity, integrity and accountability of trading communications.
  • the security protocol should be capable of resisting malicious attacks.
  • a method for secure transaction communication with a financial server in a user's mobile terminal includes the following steps: i. Creating a transaction request (req) Ii. using the private key (K" 1 ) of the user, generating a digital signature of the transaction request (req); iii. encrypting the transaction request (req) with a first key (1) and a digital signature of the transaction request (req) to obtain a ciphertext; iv. encrypting the first key (k!) using the server's public key (K B ); v. encrypting the ciphertext and the encrypted The first key (sent to the server).
  • a method for secure transaction communication with a user's mobile terminal in a financial server comprising the steps of: I. receiving a ciphertext from the mobile terminal And a first key (kj, encrypted by the server's public key (K B ), wherein the ciphertext is encrypted by the first key (1 ⁇ ), a transaction request (req), and the transaction request (req) Obtaining the digital signature of the server; II. decrypting the first key (1 ⁇ ) encrypted by the public key (K B ) of the server using the private key (KB 1 ) of the server, to obtain the first a key (kj; III.
  • the public key (K c ) determines whether the transaction request (req) matches the digital signature of the transaction request (req): When it matches, a transaction corresponding to the transaction request (req) is performed.
  • a device for secure transaction communication with a financial server in a mobile terminal corresponding to the above method, and for secure transaction communication with the mobile terminal in the financial server device of.
  • the embodiment of the present invention proposes a method for conducting mobile financial transaction communication in an application layer, where the number of interactive messages is small, and the processing performance requirement for the mobile terminal is low.
  • FIG. 1 is a flow chart of a method for secure transaction communication between a mobile terminal and a financial server, in accordance with one embodiment of the present invention
  • FIG. 2 is a schematic diagram of a string of users in accordance with an embodiment of the present invention.
  • FIG. 3 is a schematic diagram of a node n1 including digital envelopes ⁇ , ⁇ ⁇ , in accordance with one embodiment of the present invention.
  • h(m) performs a Hash operation on the message m to generate a summary of m
  • Req transaction request such as remittance or payment of mobile terminal
  • the res bank financial server's response to req must be ordered before the user can use mobile banking.
  • the user When ordering the mobile banking service, the user will obtain a public key K c automatically generated by a certain -1 mechanism and a private key K 1 corresponding to the public key.
  • the user registers the user's identity (eg, bank account number) with the user's public key ⁇ / ⁇ Kc: in the bank's continued financial server.
  • the user also obtains the bank's public key K B and stores the public key in his mobile phone. Therefore, in this embodiment, the following conditions are based:
  • the bank financial server knows the user's public key K (:.
  • the above two sets of public and private keys are asymmetric. It can be understood that the method of generating an asymmetric public key and a private key, and the handshake of the above communication parties to exchange their respective public keys
  • the mobile terminal MS When the user operates a remittance or payment transaction in an application of the mobile phone, such as a mobile banking client, first, in step S10, the mobile terminal MS generates two random symmetric session keys k using, for example, a pseudo random number as a seed. h k 2 .
  • the two keys are used for this transaction session and they are valid until the end of the transaction. Randomly generating new session keys for each transaction can avoid Reply Attacks. It can be understood that this is a preferred mode of the present invention, and the two keys may also be stored after being generated for a plurality of transactions in a predetermined time period, and automatically regenerated after a predetermined time or after completion of several transactions. of.
  • step S11 the mobile terminal MS creates a transaction request req for the transaction according to the user's remittance or payment operation, and the request may include the type of the transaction, such as remittance, payment; currency of the transaction; Amount; the object of the transaction, such as the bank account number of the other party or the identity of the merchant.
  • the message may also include the user's identification C and the bank's identification B for verification by the bank's financial services server.
  • step S12 the mobile terminal MS generates a digital signature of the transaction request req using the private key K ⁇ of the user.
  • step S120 the mobile terminal MS generates summary information h(req, k 2 ) of the new message formed by the transaction request req and the key concatenation according to a predetermined digest rule.
  • step S121 the mobile terminal MS encrypts the generated digest information using the private key of the user, and generates a digital signature ⁇ h(req, k 2 ) ⁇ Kc - l of the transaction request req.
  • a digital signature ⁇ h(req, k 2 ) ⁇ Kc - l of the transaction request req.
  • step S13 the mobile terminal MS encrypts the transaction request req and the new message formed by concatenating the digital signature of the transaction request req to obtain a ciphertext.
  • step S14 the mobile terminal MS encrypts the key sum using the server's public key K B to obtain a digital envelope 3, A 2 ⁇ 3 ⁇ 4 . Since only the financial server knows the private key K B of the server, only the financial server can unlock the digital envelope to obtain the key sum therein.
  • step S15 the mobile terminal MS sends the ciphertext M req, k 2 ) ⁇ K and the key p and the key to the financial server, that is, ⁇ req, ⁇ h(req, k 2 ) ⁇ K _, ⁇ k k , k 2 ⁇ Kb ⁇
  • the message is sent to the financial server.
  • step S20 the financial server receives the mobile terminal ⁇ req, ⁇ h( req, k 2 ) ⁇ , ⁇ kk 2 ⁇ Kr ⁇ message.
  • step S21 the present financial server using a private key KB server 1 decrypts ⁇ ⁇ , i.e. decrypts the public key of the server of the present ⁇ ⁇ and encrypted key, and get the key ⁇ k 2o
  • step S22 the financial server decrypts ⁇ req, ⁇ h(re q> k 2 ) ⁇ K?l ⁇ ki using the key to obtain a digital signature ⁇ h(req,) of the transaction request req and the transaction request (req). k 2 ) ⁇ K ,.
  • step S23 the financial server searches for and reads from the database the user's public key K c corresponding to the user identifier according to the user identifier in the transaction request req.
  • step S230 the financial server generates a summary information h' (req, k 2) for verification based on the transaction request req and the decrypted key ⁇ based on the same digest rule as the mobile terminal. ).
  • step S231 the financial server decrypts the digital signature ⁇ h(req, k 2 of the transaction request req) and obtains the digest m (req, k 2 ) of the transaction request req using the user's public key K c .
  • step S232 it is judged whether the digest information / 2 r e U of the transaction request req and the key k 2 coincides with the digest information z ⁇ r J for verification: when coincident, the financial server can determine the transaction request The req was indeed issued by the user, has not been tampered with, and is guaranteed to be accountable. Therefore, the financial server obtains the type, currency, amount, and object of the transaction from the transaction request req, and processes the transaction, deducts the corresponding amount from the bank account of the user, and pays the payment to the transaction object.
  • the transaction process ends when the financial server processes the transaction.
  • the above random key can be omitted, that is, the transaction request req
  • the summary information is determined only by the transaction request req itself.
  • the financial server after processing the transaction, the financial server also generates and sends a transaction response to the user based on the secure transaction communication.
  • secure communication for transaction response in accordance with a preferred embodiment of the present invention.
  • step S24 the financial server creates a transaction response res, which includes the processing result of the transaction request req, such as the transaction success, or the transaction failure and the cause of the failure.
  • the transaction response res may also include a bank identification B and a user identification C.
  • step S25 the financial server generates a digital signature of the transaction response res using the private key K- B ' of the server.
  • step S250 the financial server generates summary information ⁇ e of the transaction response res according to a predetermined summary rule.
  • summary rules used herein may be the same as, or different from, the digest rules used by the mobile terminal to generate the transaction request req.
  • step S251 the financial server encrypted using the private key KB 1 according to the present transaction server digest information response res 2 (e, generates a digital signature of the transaction response ⁇ h) ⁇ .
  • step S26 the financial server encrypts the transaction response res using the key ⁇ , and the digital signature ⁇ h(res) ⁇ K ⁇ of the transaction response res.
  • the financial server encrypts the key k ⁇ at the same time, and encrypts the key ⁇ res , ki , ⁇ h( res ) ⁇ ⁇ k2 .
  • step S27 the financial server sends the ciphertext, person, back to the mobile terminal MS.
  • step S16 the mobile terminal MS receives the ciphertext ⁇ ki from the financial server.
  • step S17 the mobile terminal MS decrypts the ciphertext using the session key generated by it. ⁇ res,k,, ⁇ h(res) ⁇ K _, ⁇ k2 , get the transaction response res , the digital signature f/ ⁇ r ⁇ and the key ki of the transaction response reS .
  • step S18 the mobile terminal searches for and reads the public key K B of the financial server corresponding to the bank from its database according to the bank identifier B in the transaction request response. And based on the public key K B of the server, it is determined whether the transaction response res matches the digital signature f ms ⁇ of the transaction response res, and when it matches, the corresponding processing is performed.
  • step S180 the mobile terminal generates a summary information for verification based on the transaction request res based on the same digest rule as the financial server.
  • step S181 the mobile terminal decrypts the digital signature ⁇ h(r es ) ⁇ KBi of the transaction response res using the public key K B of the financial server, and obtains the summary information h( res ) of the transaction response res .
  • step S182 the mobile terminal determines whether the digest information h(res) of the transaction response res matches the digest information h'(res) for verification, and determines whether the decrypted key is associated with the mobile terminal.
  • the generated key matches:
  • the mobile terminal can determine that the transaction response res is indeed issued by the bank, has not been tampered with, and displays to the user that the transaction has succeeded, or failed and the reason for the failure, according to the transaction response res.
  • the financial server sends the ciphertext r ⁇ Wr ⁇ A 2 , wherein the encrypted terminal does not include the encrypted key k, and the mobile terminal only judges whether the summary information of the transaction response res is ⁇ re ⁇ ) The summary information h' (res) of the check can be matched.
  • the embodiment can be implemented by using a short message:
  • the mobile phone When the user handles the banking service through the mobile phone, the mobile phone prompts to input information such as an account number, a service code, and a password.
  • the software in the mobile phone executes the above method, generates a corresponding transaction request, and encrypts the transaction request to generate a corresponding short message.
  • the mobile phone transmits the short message to the short message platform of the bank through the short message gateway of the mobile operator.
  • the bank's short message platform is linked to the bank's financial server
  • the encrypted short message is provided to the financial server.
  • the financial server After verifying the legality of the short message, the financial server processes the transaction request, generates a corresponding transaction response according to the transaction result, and encrypts the transaction response.
  • the encrypted transaction response is sent to the mobile terminal of the mobile terminal through the short message platform of the mobile terminal, and the mobile terminal verifies the legality of the short message, and then displays the transaction result indicated in the short message to the user.
  • the IP-based application software running on the mobile phone can also directly communicate with the financial server of the bank.
  • embodiments of the invention are based on secure communications in the application layer.
  • the mobile terminal can increase the security by using a secure communication protocol using the transport layer in the transport layer of the protocol stack according to its performance.
  • ⁇ ⁇ is to encrypt the message by using the public key of the data receiver. Since only the recipient has the corresponding private key, only the recipient can decrypt the message - equivalent to opening the envelope.
  • the mobile phone uses the bank public key ⁇ to encrypt the two newly generated random keys. Only the bank knows the corresponding private key, so only the bank can open the envelope.
  • the present embodiment relates to a mobile terminal, thereby reducing the amount of calculation on the mobile terminal as much as possible.
  • the message digest is first taken, and the shorter information is subjected to a computational operation with a large amount of computation, which shortens the operation time, and can ensure the integrity of the message and meet the requirements of the accountability.
  • the random key in the digital envelope ⁇ 2 ⁇ is generated by the mobile phone. Although generating a random number will increase the overhead of the mobile phone, the bank does not need to use a digital envelope to package the new key and send it to the mobile phone. Therefore, the mobile terminal reduces the time-consuming public key decryption operation. Obviously this can reduce the total amount of calculations on the mobile phone side.
  • public key encryption and symmetric encryption are combined, public key encryption is used to transmit a symmetric key, and symmetric encryption is used to protect the protocol message body.
  • public key cryptography is much lower than symmetric cryptography at the speed of computing, it can achieve sufficient security and speed up protocol execution.
  • the request message has one more digital envelope than the response message.
  • the structure, content and length of the symmetric encryption part are also different, so that their message structure is significantly different.
  • This asymmetric message structure is One of the effective means of resisting replay attacks, the attacker will not be able to use the reflex attack, that is, the transaction request message cannot be treated as a response. A message is sent to the phone, and vice versa.
  • an apparatus for secure transaction communication with a financial server in a mobile terminal comprising means for implementing the method as above, the apparatus comprising:
  • a first digital signature device for generating a digital signature ⁇ h(req, k 2 ) ⁇ K of the transaction request req, -
  • the first stack 1 is overlaid ⁇ req, ⁇ h( req, k 2 ) ⁇ ⁇ ki , ⁇ k! , k 2 ⁇ ⁇ ⁇ ⁇ m is sent to the financial server;
  • an apparatus for secure transaction communication with a mobile terminal in a financial server comprising means for implementing the method as above, the apparatus comprising:
  • the correctness of the MB protocol is mainly reflected in two aspects:
  • Strand space theory defines an attack set that contains eight types of attacker behaviors. This attack set only summarizes all the attacks currently known. Therefore, the proofs given below are based only on known attack sets.
  • a stranded space ( ⁇ , P) is a MB Strand space, if ⁇ is the union of the following three Strands:
  • the body associated with this Strand is the mobile phone user C.
  • the entity associated with this Strand is Bank B. Knowing a strand of Strand s, it can distinguish its attacker's Strand, user Strand and 4 strands Strand.
  • is MB Strand space
  • C is a Bundle in ⁇
  • s is A user's Strand with a C-height of 2.
  • ⁇ ' j C contains a bank with a C-height of 2, Strand t ⁇ .
  • n 2 is a regular node, and the sign is positive.
  • F.tr(p) is of the form ⁇ - g>, and there is no node with a positive sign.
  • T.tr(p) The form of T.tr(p) is ⁇ -g, +g, +g>, and the positive node is not very small.
  • is simple, ... 1 (or 1 [ ⁇ ] Fang 1 ⁇ 1 1, so that the positive node not appear minimal.
  • E. tr(p) takes the form ⁇ - K, -h, + ⁇ h ⁇ K > , and sets ⁇ , ⁇ / ⁇ , H. ⁇ .
  • the positive node is not very small.
  • K.tr(p) is ⁇ +k>, keKp, but k ⁇ K P , so this is not possible.
  • D. tr(p) is ⁇ - K- i +h)
  • ⁇ chAk ⁇ h from the minimum of h
  • K K B. Therefore, there is a node m, there is ⁇ ca) - but ⁇ ', so 1 can only be sent from a regular node. But no legal entity in the agreement has sent '.
  • mi can't be on the M, F, T, K attackers Strand.
  • E. tr(p) takes the form ⁇ - K,-h,+ ⁇ h ⁇ K ⁇ , if ghcterm m,), is a positive node on E-type Stmnd ⁇ ', then ghcterm p' , 2>), ⁇ ', 2>- ⁇ , and m, are contradictions between the very small elements in U.
  • the form of 0.1:1 ⁇ ) is ⁇ -1 1 , - ⁇ 11 ⁇ 1 +11>, and if ghcterm m! is a positive node on D-type Strand ⁇ ', then ghcterm( ⁇ p' , 2>) , ⁇ p' , 2> ⁇ m ⁇ is a contradiction between the very small elements in U.
  • n 2 is not on the attacker Strand, but on the regular Strand.
  • Lemma 2 In t there is a node before, such that ⁇ K K continent (" ⁇ ). Proof: as shown in Figure 3, generated in n Q , and uniquely generated in ⁇ . And ' ⁇ c ⁇ . ), But ⁇ 2 ), so ⁇ 0 ⁇ ⁇ 2 , people ⁇ does not arise from, therefore, on the Stmnd t where ⁇ 2 is located, there must be a node!!! Before ⁇ 2 , the minimum of the resulting, ⁇ ⁇ ) ⁇ ⁇ ⁇ term ⁇ n A.
  • Lemma 3 Conventional Strand t is a bank Strand contained in C, then t contains ⁇ and n 2 .
  • n 2 is a regular positive node, and after the node, and node n contains an item of the form ⁇ xy. If t is user Strand, it can only be a negative node after a node containing a ⁇ xy ⁇ k- term. But n 2 is a positive node, so t must be a bank Strand, n, and n 2 are the first node and the second node of t, respectively. Since the last node of t is contained in C, its C-height must be 2.
  • Proposition 2 If: 1) ⁇ is MB Strand space, C is a Bundle in ⁇ , s is A user's Strand with a C-height of 2.
  • m be the minimum element of F and be a regular node, then the sign of m is positive. There is only n in s. The sign is positive, but ⁇ so m is not on s . Another 1 (, the only one generated from n G , • ⁇ •m is not on other conventional Strand s' ⁇ s. Therefore m cannot be a regular node.
  • F can only be empty, so the key 1 ⁇ can only appear in the encrypted form specified by the protocol, and thus is confidential.

Description

基于应用层的移动金融业务的
安全通信方法及其装置 技术领域
本发明涉及安全通信, 尤其涉及移动通信中的基于应用层的安全 通信方法与装置。 背景技术
自传输层安全 ( Transport Layer Security, 简称 TLS )协议 1.0版以 来, 手机银行等移动金融业务的安全性主要依赖于处于传输层中的安全 协议,如无线传输层安全( Wireless Transport Layer Security,简称 WTLS ) 协议。 由于类似的原因, 目前还存在另一种称为安全电子交易 (Secure Electronic Transaction, 简称 SET )的协议。但由于其复杂性和不完备性, 该协议难以在手机应用中实现, 所以该协议没有得到广泛使用。 这几种 手机银行安全协议都有如下的缺点:
- 协议过于复杂, 例如 SET中双方有过多的来回消息, 对于双 方设备的处理性能有较高的要求, 使得该协议难以在机能较 弱的移动手机或其他移动终端中实现;
- 缺乏灵活性, 例如为了满足手机银行业务需要将整个传输层 安全通信协议栈完全实现于移动终端中。
根据最近的调查, 现有的应用层( Application Layer )协议中还没有 用于实现安全的移动金融业务的。 同样, 申请人发现, 目前需要在应用 层中设置一定的安全通信机制, 以与协议栈中的低层安全通信机制相配 合, 更好地实现安全通信的目的。 该应用层安全协议应具有如下一些特 点:
- 能够保证在移动金融业务中所有交易的安全, 即保证交易通 信的秘密性、 认证性、 完整性和可追究性。 例如, 该安全协 议应具有抵抗恶意攻击的能力。
- 双方交互的消息个数应尽可能地少, 例如使用一条请求消息 以及一条应答消息完成一个交易。 发明内容
可见, 对于移动金融业务, 目前需要一种应用层中的轻量级的安 全通信方法, 该方法需要保证交易通信的安全, 并且使用尽可能少的 消息就能够完成交易的请求以及应答通信。
就以上技术需求, 根据本发明一个方面的实施例, 提供了一种在 用户的移动终端中用于与金融服务器进行安全的交易通信的方法, 其 中, 包括如下步骤: i. 创建交易请求 (req); ii. 使用该用户的私钥 ( K"1 ), 生成所述交易请求(req)的数字签名; iii. 使用一个第一密 钥 ( l ) 加密所述交易请求 (req) 以及所述交易请求 (req) 的数字 签名, 得到一密文; iv. 使用所述服务器的公钥 (KB) 加密所述第一 密钥 ( k!); v. 将所述密文和经加密的所述第一密钥 ( 发送给所 述服务器。
根据本发明一个方面的实施例, 提供了一种在金融服务器中用于 与用户的移动终端进行安全的交易通信的方法,其中, 包括如下步骤: I. 接收来自所述移动终端的一密文和经本服务器的公钥( KB )加密的 第一密钥 (kj, 其中所述密文由所述第一密钥 (1^)加密一交易请求 (req) 以及所述交易请求(req) 的数字签名而得到; II. 使用本服务 器的私钥 ( KB1 ) 解密所述经本服务器的公钥 (KB) 加密的所述第一 密钥 (1^), 得到所述第一密钥 (kj; III. 使用所述第一密钥 (k,)解 密所述密文, 得到所述交易请求 (req) 以及所述交易请求 (req) 的 数字签名; IV. 使用所述用户的公钥 (Kc), 确定所述交易请求(req) 是否与所述交易请求(req)的数字签名相符: 当相符时, 进行与所述 交易请求 (req)相应的交易。
根据本发明另一个方面的实施例, 还提供了与以上方法对应的在 移动终端中用于与金融服务器进行安全的交易通信的设备, 以及在金 融服务器中用于与移动终端进行安全的交易通信的设备。 本发明的实施例提出了一种应用层中的用于进行移动金融交易 通信的方法, 交互消息个数少, 对移动终端的处理性能要求低。 经过
Strand (串) 空间理论证明, 本发明的优选实施例的安全性质可以得 到保证。 附图说明
通过阅读参照以下附图所作的对非限制性实施例所作的详细描 述, 本发明的其它特征、 目的和优点将会变得更加明显:
图 1 是根据本发明的一个实施例, 移动终端与金融服务器进行安 全的交易通信的方法流程图;
图 2 是根据本发明的一个实施例, 用户的串的示意图;
图 3是根据本发明的一个实施例,节点 nl包括数字信封^^,^ β的 示意图。
附图中, 相同或者相似的附图标识代表相同或者相似的部件。 具体实施方式
本实施例以一个用户使用其移动终端 MS与银行的金融服务器进 例中使用的符号进行说明: 表 1
C(Customer) 手机用户的标识 (如银行帐号)
B(Bank) 银行的标识 (如行号)
kj, k2 新产生的随机的对称会话密钥
Kc] 手机用户的签名私钥
Kc 手机用户的公钥
KB-1 银行的签名私钥
KB 银行的公钥
{m}k 用对称密钥 k加密消息 m { mk-' 用私钥 IC1签名, 即加密消息 m
mi ,m2 消息 和 m2串联后构成的新消息
h(m) 对消息 m进行 Hash运算, 生成 m的摘要
req 移动终端的汇款或支付等交易请求
res 银行金融服务器对 req的响应结果,例如交易处 理成功, 或交易处理失败及失败原因 在用户使用手机银行业务前, 他必须订购这一业务。 在订购手机 银行业务时, 用户将获得通过一定 - 1的机制自动产生的公钥 Kc和与该 公钥相对应的私钥 K 1。 该用户在银行续的金融服务器中注册该用户的 标识 (例如银行帐号) 以及该用户的公钥 \ / Ϊ Kc:。 同时, 该用户也获得 银行的公钥 KB, 并将该公钥存储于其手机中。 因此, 本实施例中基 于如下条件:
- 只有该用户知晓其私钥 κ -1
- 该用户知晓该银行金融服务器的公钥 κβ
- 只有该银行金融服务器知晓其私钥 KB1 ;
- 该银行金融服务器知晓该用户的公钥 K (:。
以上两组公钥和私钥都是非对称的。 可以理解, 生成非对称的公 钥以及私钥的方法, 以及以上通信双方交换各自公钥的握手
( Handshake ) 过程也是本领域的一般技术人员所熟知的, 本发明在 此不做赘述。
在用户在手机的应用程序, 例如手机银行客户端中操作进行汇款 或支付交易时, 首先, 在步驟 S 10中, 移动终端 MS以例如伪随机数 作为种子产生两个随机的对称会话密钥 kh k2。 该两个密钥是用于本 次交易会话的, 它们的有效期到本次交易结束。 对每个交易随机产生 新的会话密钥可以避免重发攻击(Reply Attacks )。 可以理解, 这是本 发明的一个优选方式, 该两个密钥也可以是生成后存储起来, 用于预 定时间段的数个交易, 到预定时间后或数个交易完成后自动重新生成 的。
在步骤 Sl l中, 移动终端 MS根据用户的汇款或支付的操作, 创 建用于本次交易的交易请求 req, 该请求中可以包括交易的类型, 例 如汇款、 支付; 交易的币种; 交易的金额; 交易的对象, 例如对方的 银行帐号或商户的标识。该消息中还可以包括用户的标识 C和银行的 标识 B, 以便银行的金融服服务器进行核实。
接着, 在步骤 S12中, 移动终端 MS使用本用户的私钥 K^ , 生 成交易请求 req的数字签名。
在一个实施例中, 在步骤 S120里, 移动终端 MS按一预定的摘 要规则, 生成交易请求 req和密钥 串联后构成的新消息的摘要信息 h( req, k2 )。
而后, 在步骤 S121里, 移动终端 MS使用用户的私钥 加密所 生成的摘要信息, 生成交易请求 req的数字签名 {h(req, k2 )}Kcl 。 可以理解, 生成数字签名的方法并不限于以上这一种, 数字签名的 使用是本领域的一般技术人员所熟知的, 本发明在此不对其他方法进行 赘述。
随后,在步骤 S13中,移动终端 MS使用密钥 加密交易请求 req 以及交易请求 req 的数字签名串联后构成的新消息, 得到一密文
{req, {h(req, k2 )}K_, }ki
并且, 在步骤 S14中, 移动终端 MS使用服务器的公钥 KB加密 密钥 和 , 得到一个数字信封 ¾,A2}¾。 由于只有金融服务器知晓 服务器的私钥 KB 所以只有金融服务器才能够该数字信封解开得到 其中的密钥 和 。
而后,在步骤 S 15中,移动终端 MS将密文 ί M req, k2 )}K 和 经力 p 密 的 密钥 和 ^ 发送给金融服务器 , 即 将 {{req,{h(req, k2 )}K_, }k k , k2 }Kb }消息发送给金融服务器。 在步骤 S20 中 , 金融服务器接收到 来 自 移动终端 {{req,{h( req, k2 )}^ ,{k k2 }Kr }消息。
而后, 在步骤 S21 中, 金融服务器使用本服务器的私钥 KB1解密 { }Κβ , 即解密经本服务器的公钥 ΚΒ加密的密钥 和 , 得到密 钥 ^和 k2o
接着, 在步驟 S22 中 , 金融服务器使用 密钥 解密 {req,{h(req>k2)}K?l}ki , 得到交易请求 req以及交易请求(req)的数字 签名 {h(req,k2)}K,。 随后, 在步骤 S23中, 金融服务器根据交易请求 req中的用户标识, 从其数据库中搜索并读取到与该用户标识对应的该用户的公钥 Kc。 并 基于该用户的公钥 Kc确定交易请求 req是否与交易请求 req的数字签 名 {h(req,k2)}Kcl ^符, 当相符时, 处理该交易请求 req, 进行相应的 六 且
又^。
在一个实施例中, 在步骤 S230里, 金融服务器基于与移动终端相 同的摘要规则, 基于交易请求 req和解密得到的密钥 ^, 生成一用于校 验的摘要信息 h' (req, k2 )。
而后, 在步骤 S231里, 金融服务器使用用户的公钥 Kc, 解密交易 请求 req的数字签名 {h(req,k2 , 得到交易请求 req和密钥 的摘 要 m (req,k2)。
随后, 在步骤 S232 里, 判断交易请求 req和密钥 k2的摘要信息 /2 re U是否与用于校验的摘要信息 z丫 r J相符: 当相符时, 金 融服务器可以确定该交易请求 req确实是由该用户发出, 没有被篡改 过, 并且保证了可追究性。 因此金融服务器从交易请求 req中获取到 该交易的类型、 币种、 金额和对象等, 并处理本次交易, 从该用户的 银行帐户中扣除相应的款项, 将该款项支付给交易对象。
在一种情况下, 在金融服务器处理交易后, 交易过程即告结束。 在这种情况下, 以上随机的密钥 是可以省去的, 即交易请求 req的 摘要信息仅由交易请求 req本身而确定。
在另一种情况下, 在处理交易完毕后, 金融服务器还生成并基于 安全的交易通信发送一个交易应答给用户。 以下对根据本发明的优选 实施例进行交易应答的安全通信进行详述。
在步骤 S24 中, 金融服务器创建一交易应答 res, 该交易应答中 包括对交易请求 req的处理结果, 例如交易成功, 或交易失败以及失 败原因等。 交易应答 res中还可以包括银行标识 B以及用户标识 C。
在步驟 S25 中, 金融服务器使用本服务器的私钥 K-B', 生成交易 应答 res的数字签名。
在一个实施例中, 在步骤 S250里, 金融服务器按一预定的摘要规 则, 生成交易应答 res的摘要信息 ^ e 。 可以理解, 这里使用的摘 要规则可以与移动终端生成交易请求 req时所用的摘要规则相同, 或 者不同。
在步驟 S251 里, 金融服务器使用本服务器的私钥 K-B1加密交易应 答 res的摘要信息 2( e , 生成所述交易应答的数字签名 {h )^ 。
可以理解, 生成数字签名的方法并不限于以上这一种, 数字签名的 使用是本领域的一般技术人员所熟知的, 本发明在此不对其他方法进行 赘述。
在步骤 S26中, 金融服务器使用密钥 ^加密交易应答 res, 交易 应答 res 的数字签名 {h(res)}K^ 。 优选地, 金融服务器同时加密密钥 k} , 加密后得 —密 { res , k i ,{ h( res )} }k2 。 在步骤 S27中, 金融服务器将密文 ^, 人,发送回移动 终端 MS。
在步骤 S16 中, 移动终端 MS 接收来自金融服务器的密文 }ki
Figure imgf000009_0001
在步骤 S17 中, 移动终端 MS使用其生成的会话密钥 ^解密密文 {res,k,,{h(res)}K_, }k2 , 得到交易应答 res , 交易应答 reS 的数字签名 f/^r^ 和密钥 ki。 在步骤 S 18中, 移动终端根据交易请求应答中的银行标识 B , 从其 数据库中搜索并读取与该银行对应的该金融服务器的公钥 KB。 并基于 该服务器的公钥 KB确定交易应答 res是否与交易应答 res的数字签名 f ms ^^相符, 当相符时, 进行相应的处理。
在一个实施例中, 在步骤 S 180里, 移动终端基于与金融服务器相 同的摘要规则, 基于交易请求 res, 生成一用于校验的摘要信息?丫 入 而后, 在步骤 S 181里, 移动终端使用金融服务器的公钥 KB, 解密 交易应答 res 的数字签名 {h(res)}KBi , 得到交易应答 res 的摘要信息 h( res )。 随后,在步驟 S 182里,移动终端判断交易应答 res的摘要信息 h(res ) 是否与用于校验的摘要信息 h' (res)相符, 同时判断解密得到的密钥 是否与本移动终端所生成的密钥 相符: 当相符时, 移动终端可以 确定该交易应答 res确实是由该银行发出, 没有被篡改过, 并根据交 易应答 res向用户显示该交易已经成功, 或失败及失败原因。 可以理 解, 在另一情况下, 金融服务器发送密文 r^Wr^^^ A2, 其中不包 括经加密的密钥 k 则移动终端仅判断交易应答 res的摘要信息 ^re^) 是否与用于校验的摘要信息 h' (res)相符即可。 在具体实现中, 本实施例可以以短信的方式实现: 当用户通过手 机办理银行业务时, 手机提示输入帐号、 业务代码、 密码等信息。 手 机中的软件执行以上的方法, 生成相应的交易请求, 并将交易请求加 密生成相应的短消息。 手机把短消息通过移动运营商的短消息网关传 输到银行的短消息平台。 银行的短消息平台与银行的金融服务器相 连, 将该加密的短消息提供给金融服务器。 金融服务器验证该短信的 合法性后处理交易请求, 再根据交易结果生成相应的交易应答, 并将 交易应答加密。 而后将加密的交易应答通过银行的短消息平台, 经移 动运营商的短消息网关发给用户的移动终端, 移动终端验证该短信的 合法性后将该短信中指示的交易结果显示给用户。
本实施例也可以通过手机上运行的基于 IP协议的应用软件直接 与银行的金融服务器进行通信。
可以理解, 本发明的实施例是基于在应用层中的安全通信。 移动终 端可以根据其性能, 同时在协议栈的传输层中增加使用传输层的安全通 信协议, 提高安全性。
本实施例中使用的数字信封 , } ^是利用数据接收者的公钥 加密消息, 由于只有接受者才拥有对应的私钥, 因此只有接受者才能 解密消息-相当于打开该信封。 手机用银行公钥 ΚΒ加密两个新产生 的随机密钥,只有银行知道对应的私钥,故只有银行才能打开该信封。
对于运算强度, 本实施例涉及到移动终端, 因此尽可能地减少移 动终端上的计算量。 本实施中先取消息摘要, 再对该较短的信息进行 运算量较大的签名运算, 缩短了运算时间, 并且既能保证消息的完整 性, 又能满足可追究性的要求。 数字信封 { 2}^中的随机密钥 和 都由手机端产生, 虽然多产生一个随机数会增大手机端的开销, 但这样银行端就无需再用一个数字信封包装新密钥发给手机端, 从而 使手机端减少了一次耗时的公钥解密运算。 显然这样可以降低手机端 的总计算量。 本实施例将公钥加密和对称加密结合, 公钥加密用于传 递对称密钥, 对称加密用于保护协议消息主体。 考虑到在运算速度上 公钥加密要远低于对称加密, 这样做既可以获得足够的安全性, 又能 加快协议执行的速度。
对于请求和应答的对称性, 请求消息要比应答消息多一个数字信 封, 对称加密部分的结构、 内容和长度也不相同, 从而使它们的消息 结构存在显著不同, 这种非对称的消息结构是抵抗重放攻击的有效手 段之一, 攻击者将无法使用反射攻击, 即不能把交易请求消息当作应 答消息发送手机端, 反之亦然。 根据本发明的另一个实施例,还提供了在移动终端中用于与金融服 务器进行安全的交易通信的设备, 该设备包括用于实现如以上方法的 装置, 该装置包括:
- 密钥生成器, 用于生成密钥 ^和
- 交易请求装置, 用于生成交易请求 req;
- 第一数字签名装置, 用于生成交易请求 req 的数字签名 {h(req,k2)}K.,-
- 第一加密装置, 用于生成密文 , (^ ^J^^ ;
- 第二加密装置, 用于生成数字信封 , ¾} ;
- 第一 迭装1 , 于复迭 {{ req,{ h( req, k 2 )} } ki ,{ k! , k 2 } κ β } m 发送给金融服务器;
- 第二接收装置, 用 于接收来 自 金融服务器的 密文
{res,k,,{h(res)}K^ }ki
- 第三解密装置, 用
Figure imgf000012_0001
- 第二处理装置, 用于验证交易应答 res 是否与数字签名
Figure imgf000012_0002
相符, 并在相符时进行相应的处理。 根据本发明的另一个实施例,还提供了在金融服务器中用于与移动 终端进行安全的交易通信的设备, 该设备包括用于实现如以上方法的 装置, 该装置包括:
- 第一接收装置, 于接^ }ki,{k!,k2}Kii}
Figure imgf000012_0003
息;
- 第一解密装置, 用于解密 , ^; - 第二解密装置, 于 密 {req, {h(req, k2 )} }ki
- 第一处理装置, 用于验证交易请求 req和密钥 是否与数字签名
{ H , k2 )}κ }相符 , 并在相符时进行相应的交易;
- 交易应答装置, 用于生成交易应答 res;
- 第二数字签名装置, 用于交易应答 res的数字签名 ;
Figure imgf000013_0001
- 第三加密装置, 用于生成密文^^, , ^^^^人2
- 第二发送装置, 用于将密文^^ ,
Figure imgf000013_0002
发送回移动终端
MS。 以上从方法以及装置的角度本发明的优选实施例进行了描述, 以下 使用 Strand空间理论, 对本发明的优选实施例的安全性进行证明。
在 Strand空间中, MB协议的正确性主要体现在两个方面:
( 1 )认证属性: 当认证主体以某参数完成其协议后,被认证主体也 必须以该参数参与协议运行。
( 2 )秘密属性: 保护协议消息不被泄漏给未被授权的主体。
需要指出的是: Strand空间理论中定义了一个包含八种攻击者行为 的攻击集, 该攻击集只概括了目前已知的所有攻击。 因此下面给出的证 明只是建立在已知攻击集基础上的。
Strand空间
定义 1 .一个存在攻击的 Strand空间 (∑, P)是一个 MB Strand空间, 如果∑是以下三个 Strands的并集:
1 )攻击者的 Strands p e P。
2)用户 Strands
Figure imgf000013_0003
其迹为:
+ { {req, {h(C, B, req, k2 )}K_} }, , {k , ^2}^ },-{res, kx , {h(B, C, res)} 其中 C,BeT, k1?k2eK,
Figure imgf000014_0001
所有 Strands的集合。 与此 Strand关联的主体是手机用户 C。
3)银行 Strands t≡ Bank[B,C,kbk2,req,res] , 其迹为:
(- Ur q, {h(C, B, req, k2)} ^ }/ , {k },+{res, k,{h{B,C, res)}^ } 〉 其中 C,BGT, kl5k2GK,
Figure imgf000014_0002
Strands的集合。 与此 Strand关联的主体是银行 B。 已知一个∑中 Strand s, 可以 居它的迹唯一区分出攻击者的 Strand、 用户 Strand和 4艮行 Strand„
认证属性的证明 命题 1
若: 1) ∑是 MB Strand 空间, C 是∑中的一个 Bundle, s 是
Figure imgf000014_0003
中的一个 C-高度为 2的用户 Strand。
3)k!≠k2, 且 kbk2唯一产生于∑。
贝' j : C 包含一个 C- 高 度为 2 的 银行 Strand t ≡
Figure imgf000014_0004
用户 Strand如图 2所示, 下面通过几个引理证明此命题:
引理 -i . b^y = {n e C kl c uns _term{n) Λ {k{,k2}Kg <Z uns _term{n)} ^,-^ _ 个
≤ -minimal节点 n2 , n2是常规节点 , 且符号为正。
证明: 由于
Figure imgf000014_0005
所以 产生于 n。。 由图 2可知 n3 GC, n3ev, 所以 V非空, 那么 V至少有一个≤- minimal成员 n2, 其 符号为正。 n2能否出现在攻击者的 Strandp上, 有以下几种可能:
M.tr(p)的形式为 〈+t〉,tET, ^τ λκ = φ ^ 而 kieK, 所以 t≠k,, 该 情况不可能。
F.tr(p)的形式为 〈- g〉,没有符号为正的节点。
T.tr(p)的形式为 <-g,+g,+g>, 正节点不是极小出现。
C. tr(p)的形式为 〈- g,-h,+gh〉, 设 term(n2)=+gh。 ··· 是简单的, ... 1(1§或]^1匚11, 所以, 正节点不是极小出现。
E. tr(p)的形式为 〈 - K,-h, +{h}K > , 设 ^ , {/^ ,
Figure imgf000015_0001
H .·.正节点不是极小出现。
K.tr(p)的形式为 〈+k〉, keKp, 但 k^KP, 故此情况不可能。
D. tr(p)的形式为 〈- K- i +h), ^chAk ^^h, 由 h的极小 性, 可设 ^^, 由自由加密假设, 得 h^k }, K=KB。 故存在一 个节点 m, 有^咖) -但^' , 所以 1只能发自一个常规节点。 但协 议中没有哪个合法主体发送过 '。
S. tr(p)的形式为〈 - gh,+g,+h〉,不失一t殳性,设 term(n2)=g , term(n2)=h 的情况是对称的。 ·Ί^ Κ , 由 g的极小性, 可设 A c , 又 是简单^ j , Ui) ch。 记11 = {m e C m n2 A gh匚 u — termim } , 因为 term(<p,l>)=- gh, it<p,l>eu, U非空, U至少有一个极小元
显然, mi不可能在 M,F,T,K型的攻击者 Strand上。
S.tr(p)的形式为〈- gh,+g,+h〉,若 S型 Strand p ' 上的一个正节点, 则 ghcterm(<p' ,
Figure imgf000015_0002
与 是 U中 极小元矛盾。
E. tr(p)的形式为〈- K,-h,+{h}K〉, 若 ghcterm m,), 是 E型 Stmnd ρ' 上的一个正节点, 则 ghcterm p' ,2>), <ρ' ,2>-<Ώΐ , 与 m,是 U中 极小元矛盾。 0.1:1^)的形式为〈-1 1,-{11}1 +11〉,若 ghcterm m!), 是 D型 Strand ρ' 上的一个正节点, 则 ghcterm(<p' ,2>), <p' ,2>^m^ 与 是 U中 极小元矛盾。
C. tr(p)的形式为 〈- g,- h,+gh〉, 若 ghctermO,), 1^是( 型 Strand p ' 上的一个正节点, 贝1 J
Figure imgf000016_0001
term(<p ,l>)=g= term(n2), i <p '
Figure imgf000016_0002
与 n2是 V中极小元矛盾。
因此, n2不在攻击者 Strand上, 而在常规 Strand上。
引理 2 在 t中, 存在一个节点 在 之前, 使得 ^K K 洲 ("Ί)。 证明:如图 3所示, 产生于 nQ,且唯一产生于∑。又 ' } c ίε 。 ), 但 ― 2),故 η0≠η2, 人^不产生于 , 因此,在 η2所在的 Stmnd t上, 必有一节点!!!在 Π2之前, 使得 由 的极小性, 得 { ^ )κΒ ^ term{nA)。 引理 3 常规 Strand t是一个包含在 C中的银行 Strand, 则 t包含 ηι 和 n2
证明: n2是一个常规正节点, 并且在节点 之后, 而节点 n,包含形 如 {xy 的项。如果 t是用户 Strand,则在包含形如 {xy}k项的节点之后只 能是负节点。 但 n2是正节点, 因此, t一定是一个银行 Strand, n,和 n2 分别是 t的第一个节点和第二个节点。 由于 t的最后一个节点包含在 C 中, 它的 C-高度一定是 2。
根据引理 2和引理 3, 命题 1立即得证。
秘密属性的证明
下面证明协议中产生的密钥 kbk2是保密的。
命题 2 若: 1) ∑是 MB Strand 空间, C 是∑中的一个 Bundle, s 是
Figure imgf000017_0001
中的一个 C-高度为 2的用户 Strand。
2) O〖, ^。
3) ki≠k2, 且 klk2唯一产生于 。
则: 对所有节点 mGC, 当
Figure imgf000017_0002
c to m)或 者 {res, kx , {h(B, C, res)} K_, }ki a termini) 证明: 设
Figure imgf000017_0003
考 ^ F~ {neC :k} term(n) A {k , k2}KB c term(n) A V3 (t term n)} 设 p非六 则 F至少有一个极小元。 下面先证明这些极小元不是常规结点, 再证明 它们也不是攻击结点, 因此 F 为空, 命题得证。
设 m是 F的极小元, 且是常规结点, 则 m的符号为正。 在 s中只 有 n。的符号为正, 但^^ 所以 m不在 s上。 又 1(,唯一产生 于 nG, •■•m 不在其他常规 Strand s'≠s上。 故 m不可能是常规结点。
F的极小元不是攻击节点的证明和引理 1的证明极为相似, 只是在 考虑 D 型攻击者 Strand 时, 要多 考虑一种情况, 即: W,k具 c,o K=k2。这时, 必须有一个节点 有 term(n)=k2, 但 k2 KP, 所以 k2只能发自一个常规节点。 但协议中没有哪个合法主体 发送过 k2o
综上所述, F只能为空, 所以密钥 1^只能以协议规定的加密形式出 现, 因而是保密的。
密钥 k2的地位和 是等价的, 其保密性的证明与 完全类同, 不 再赘述。 交易请求 req的秘密性证明也是类似的。 尽管在附图和前述的描述中详细阐明和描述了本发明, 应认为该阐 明和描述是说明性的和示例性的, 而不是限制性的; 本发明不限于所上 述实施方式。
那些本技术领域的一般技术人员可以通过研究说明书、 公开的内容 及附图和所附的权利要求书, 理解和实施对披露的实施方式的其他改 变。 在权利要求中, 措词 "包括" 不排除其他的元素和步骤, 并且措辞 "一个" 不排除复数。 在发明的实际应用中, 一个零件可能执行权利要 求中所引用的多个技术特征的功能。 权利要求中的任何附图标记不应理 解为对范围的限制。

Claims

权 利 要 求 书
1. 一种在用户的移动终端中用于与金融服务器进行安全的交易 通信的方法, 其中, 包括如下步骤:
1. 创建交易请求 (req);
ii. 使用本用户的私钥 ( i 1 ), 生成所述交易请求 (req) 的数字 签名;
iii. 使用一个第一密钥 ( 加密所述交易请求(req) 以及所述 交易请求 (req) 的数字签名, 得到一密文;
iv. 使用所述服务器的公钥 (KB)加密所述第一密钥 ( ; v. 将所述密文和经加密的所述第一密钥( 发送给所述服务器。
2. 根据权利要求 1所述的方法, 其特征在于, 所述步驟 ii包括:
111. 按第一预定规则, 生成所述交易请求 (req) 的摘要信息;
112. 使用所述用户的私钥 ( I 1 ) 加密所述摘要信息, 生成所述 交易请求 (req) 的数字签名。
3. 根据权利要求 1或 2所述的方法, 其特征在于, 所述步骤 iii 之前包括以下步骤:
- 生成用于本次交易的所述第一密钥 (k,);
4. 根据权利要求 3所述的方法,其特征在于, 所述步驟 ii之前包 括以下步驟:
- 生成用于本次交易的一个第二密钥 (k2);
所述步骤 iil进一步包括:
- 生成所述交易请求 (req) 和所述第二密钥 ( k2 ) 两者的摘要, 作为所述摘要信息;
所述步骤 iv还包括:
- 使用所述服务器的公钥 (KB) 加密所述第一密钥 (k,) 和所述 第二密钥 (k2);
所述步骤 V还包括:
- 将经加密的所述第一密钥 (kj 和所述第二密钥 (k2) 发送给 所述服务器。
5. 根据权利要求 1, 2和 4中任一项所述的方法, 其特征在于, 该方法还包括如下步骤:
vi. 接收来自所述服务器的另一密文, 所述另一密文由所述服务 器使用所述第二密钥 (k2)加密一交易应答(res) 以及所述交易应答
(res) 的数字签名而得到;
vii. 使用所述第二密钥 (k2) 解密所述另一密文, 得到所述交易 应答(res) 以及所述交易应答(res) 的数字签名;
viii. 使用所述服务器的公钥 (KB), 确定所述交易应答(res)是 否与所述交易应答(res)的数字签名相符: 当相符时, 进行相应的处 理。
6. 根据权利要求 5所述的方法,其特征在于,所述交易应答(res) 的数字签名由所述服务器使用该服务器的公钥 ( ΚΒ' ) 加密所述交易 应答(res)按第二预定规则生成的摘要信息而得到, 所述步骤 viii进 一步包括如下步骤:
viiil. 按第二预定规则, 基于所解密的所述交易应答(res), 生成 一用于校验的摘要信息;
viii2. 使用所述服务器的公钥 (KB) 解密所述交易应答(res) 的 数字签名, 得到所述交易应答(res) 的按第二预定规则的摘要信息; viii3. 判断所述交易应答(res) 的按第二预定规则的摘要信息是 否与所述用于校验的摘要信息相符: 当相符时, 进行相应的处理。
7. 根据权利要求 6所述的方法, 其特征在于, 所述另一密文由所 述服务器使用所述第二密钥 (k2) 加密所述交易应答 (res)、 所述交 易应答(res)的数字签名和所述第一密钥 (k, )而得到, 所述步骤 vii 还包括:
- 使用所述第二密钥 (k2) 解密所述另一密文, 得到所述交易应 答(res)、 所述交易应答(res) 的数字签名和所述第一密钥 ( ); 所述步骤 viii3还包括:
- 判断所解密的所述第一密钥 (kj 是否与本移动终端生成的所 述第一密钥 (l )相符: 当相符时, 进行相应的处理。
8. —种在金融服务器中用于与用户的移动终端进行安全的交易 通信的方法, 其中, 包括如下步骤:
I. 接收来自所述移动终端的一密文和经本服务器的公钥( KB )加 密的第一密钥 (l ), 其中所述密文由所述第一密钥 (k,)加密一交易 请求 (req) 以及所述交易请求 (req) 的数字签名而得到;
II. 使用本服务器的私钥( KB1 )解密所述经本服务器的公钥(KB ) 加密的所述第一密钥 (ki), 得到所述第一密钥 (kj;
III. 使用所述第一密钥 (kj 解密所述密文, 得到所述交易请求 (req) 以及所述交易请求 (req) 的数字签名;
IV. 使用所述用户的公钥 (Kc), 确定所述交易请求 (req) 是否 与所述交易请求(req)的数字签名相符: 当相符时, 进行与所述交易 请求 ( req )相应的交易。
9. 根据权利要求 8所述的方法,其特征在于,所述交易请求(req) 的数字签名由所述移动终端使用该用户的私钥 ( ί^1 ) 加密所述交易 请求 (req)按第一预定规则生成的摘要信息而得到, 所述步骤 IV进 一步包括以下步骤:
IV1. 按所述第一预定规则, 基于所解密的所述交易请求 (req), 生成一用于校验的摘要信息;
IV2. 使用所述用户的公钥 (Kc) 解密所述交易请求 (req) 的数 字签名, 得到所述交易请求 (req) 的按第一预定规则的摘要信息;
IV3. 判断所述交易请求 (req) 的按第一预定规则的摘要信息是 否与所述用于校验的摘要信息相符: 当相符时, 进行与所述交易请求 ( req )相应的交易。
10. 根据权利要求 9所述的方法,其特征在于,所述交易请求( req ) 的数字签名由所述移动终端使用该用户的私钥 ( ) 加密所述交易 请求(req)和一个第二密钥 ( k2 ) 两者的按第一预定规则的摘要信息 而得到, 所述步驟 I进一步包括:
- 接收来自所述移动终端的经本服务器的公钥 (KB)加密的所述 第一密钥 (k 和所述第二密钥 (k2);
所述步骤 II进一步包括:
- 使用使用本服务器的私钥 ( KB1 ) 解密所述经本服务器的公钥 (KB)加密的所述第一密钥 (1^)和所述第二密钥 (k2), 得到所述第 一密钥 (k2) 和所述第二密钥 (k2);
所述步骤 IV1 包括:
- 按所述第一预定规则, 基于所解密的所述交易请求(req)和解 密得到的所述第二密钥 (k2), 生成所述用于校验的摘要信息;
所述步骤 IV2包括:
- 使用所述用户的公钥 (Kc)解密所述交易请求(req)的数字签 名, 得到所述交易请求(req)和所述第二密钥 ( k2 ) 两者的按第一预 定规则的摘要信息;
所述步骤 IV3包括:
- 判断所述交易请求(req)和所述第二密钥两者的按第一预定规 则的摘要信息是否与所述用于校验的摘要信息相符: 当相符时, 进行 与所述交易请求 (req)相应的交易。
11. 根据权利要求 8至 10中任一项所述的方法, 其特征在于, 该 方法还包括如下步驟:
V. 创建一交易应答 (res);
VI. 使用所述本服务器的私钥 ( KB' ), 生成所述交易应答(res) 的数字签名;
VII. 使用所述第二密钥 (k2)加密所述交易应答(res) 以及所述 交易应答 (res) 的数字签名, 得到另一密文;
VIII. 将所述另一密文发送给所述移动终端。
12. 根据权利要求 11所述的方法, 其特征在于, 所述步骤 VI进 一步包括如下步驟:
- 按第二预定规则, 生成所述交易应答(res) 的摘要信息; - 使用所述本服务器的私钥 ( ' ) 加密所述交易应答 (res) 的 摘要信息, 生成所述交易应答的数字签名。
13. 根据权利要求 12所述的方法, 其特征在于, 所述步骤 VII进 一步包括:
- 使用所述第二密钥(k2 )加密所述交易应答(res ), 所述交易应 答(res ) 的数字签名和所述第一密钥 (^ ), 得到所述另一密文。
14. 一种在移动终端中用于与金融服务器进行安全的交易通信的 设备, 其中, 包括用于实现如权利要求 1至 7中任一项中所述方法的 装置。
15. 一种在金融服务器中用于与移动终端进行安全的交易通信的 设备, 其中, 包括用于实现如权利要求 8至 13 中任一项中所述方法 的装置。
PCT/CN2009/072386 2008-12-12 2009-06-22 基于应用层的移动金融业务的安全通信方法及其装置 WO2010066127A1 (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CN200980136629.6A CN102239714B (zh) 2008-12-12 2009-06-22 基于应用层的移动金融业务的安全通信方法及其装置
US13/139,773 US20110320359A1 (en) 2008-12-12 2009-06-22 secure communication method and device based on application layer for mobile financial service

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US20160108P 2008-12-12 2008-12-12
US61/201,601 2008-12-12

Publications (1)

Publication Number Publication Date
WO2010066127A1 true WO2010066127A1 (zh) 2010-06-17

Family

ID=42242321

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2009/072386 WO2010066127A1 (zh) 2008-12-12 2009-06-22 基于应用层的移动金融业务的安全通信方法及其装置

Country Status (3)

Country Link
US (1) US20110320359A1 (zh)
CN (1) CN102239714B (zh)
WO (1) WO2010066127A1 (zh)

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8892876B1 (en) * 2012-04-20 2014-11-18 Trend Micro Incorporated Secured application package files for mobile computing devices
US9197408B2 (en) * 2013-05-10 2015-11-24 Sap Se Systems and methods for providing a secure data exchange
CN103532927A (zh) * 2013-07-30 2014-01-22 北京中科金财科技股份有限公司 一种基于移动终端的金融云安全服务平台和数据保护方法
CN104767613B (zh) * 2014-01-02 2018-02-13 腾讯科技(深圳)有限公司 签名验证方法、装置及系统
US9208348B1 (en) * 2014-01-15 2015-12-08 Symantec Corporation Systems and methods for managing encrypted files within application packages
US9930067B1 (en) 2014-12-18 2018-03-27 Amazon Technologies, Inc. Techniques for secure session reestablishment
US9961055B1 (en) * 2014-12-18 2018-05-01 Amazon Technologies, Inc. Inaccessibility of data to server involved in secure communication
CN105323070B (zh) * 2015-02-09 2018-12-21 北京中油瑞飞信息技术有限责任公司 一种基于数字信封的安全电子邮件实现方法
US9762385B1 (en) 2015-07-20 2017-09-12 Trend Micro Incorporated Protection of program code of apps of mobile computing devices
CN109547461A (zh) * 2018-12-13 2019-03-29 如般量子科技有限公司 基于p2p对称密钥池的抗量子计算区块链保密交易系统和方法
KR20240009883A (ko) 2022-07-14 2024-01-23 주식회사 메디컬에이아이 심전도 기반 신경망 모델의 학습 방법, 프로그램 및장치

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1262770A (zh) * 1998-01-26 2000-08-09 松下电器产业株式会社 数据记录/再现方法、数据记录/再现系统、记录设备、再现设备和节目记录媒体
CN1677409A (zh) * 2004-04-02 2005-10-05 华为技术有限公司 一种通过移动网络传递交易信息的方法及系统
CN101242271A (zh) * 2008-01-24 2008-08-13 陕西海基业高科技实业有限公司 可信的远程服务方法及其系统

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7096494B1 (en) * 1998-05-05 2006-08-22 Chen Jay C Cryptographic system and method for electronic transactions
JP2002007934A (ja) * 2000-06-26 2002-01-11 Fujitsu Ltd 電子商取引システムおよび電子商取引方法
WO2002082387A1 (en) * 2001-04-04 2002-10-17 Microcell I5 Inc. Method and system for effecting an electronic transaction
US7957532B2 (en) * 2006-06-23 2011-06-07 Microsoft Corporation Data protection for a mobile device

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1262770A (zh) * 1998-01-26 2000-08-09 松下电器产业株式会社 数据记录/再现方法、数据记录/再现系统、记录设备、再现设备和节目记录媒体
CN1677409A (zh) * 2004-04-02 2005-10-05 华为技术有限公司 一种通过移动网络传递交易信息的方法及系统
CN101242271A (zh) * 2008-01-24 2008-08-13 陕西海基业高科技实业有限公司 可信的远程服务方法及其系统

Also Published As

Publication number Publication date
CN102239714B (zh) 2016-06-01
CN102239714A (zh) 2011-11-09
US20110320359A1 (en) 2011-12-29

Similar Documents

Publication Publication Date Title
AU2021203815B2 (en) Methods for secure cryptogram generation
WO2010066127A1 (zh) 基于应用层的移动金融业务的安全通信方法及其装置
US20210367753A1 (en) Trusted measurement and control network authentication method based on double cryptographic values and chaotic encryption
JP4603252B2 (ja) ユニバーサル一般取引のためのセキュリティフレームワーク及びプロトコル
KR101237632B1 (ko) 토큰과 검증자 사이의 인증을 위한 네크워크 헬퍼
CN103338215B (zh) 基于国密算法建立tls通道的方法
US7702898B2 (en) Method for authenticating and verifying SMS communications
CN101902476B (zh) 移动p2p用户身份认证方法
US20060195402A1 (en) Secure data transmission using undiscoverable or black data
CN109728909A (zh) 基于USBKey的身份认证方法和系统
CN111756529B (zh) 一种量子会话密钥分发方法及系统
JP2008503966A (ja) 匿名証明書呈示に関する匿名証明書
JP2000511382A (ja) 第1のコンピュータユニットと第2のコンピュータユニットの間の暗号化キー管理方法
CN103684798B (zh) 一种用于分布式用户服务间认证方法
CN107800675A (zh) 一种数据传输方法、终端以及服务器
CN112351037B (zh) 用于安全通信的信息处理方法及装置
WO2008031301A1 (fr) Procédé d&#39;authentification d&#39;identité en ligne point à point
TW201537937A (zh) 統一身份認證平臺及認證方法
CN111756528B (zh) 一种量子会话密钥分发方法、装置及通信架构
CN108599926A (zh) 一种基于对称密钥池的HTTP-Digest改进型AKA身份认证系统和方法
CN113507372A (zh) 一种接口请求的双向认证方法
CN114143117A (zh) 数据处理方法及设备
KR20120091618A (ko) 연쇄 해시에 의한 전자서명 시스템 및 방법
CN114726538A (zh) 一种基于区块链环签名的隐蔽通信方法
CN106330430B (zh) 一种基于ntru的第三方移动支付方法

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 200980136629.6

Country of ref document: CN

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

Ref document number: 09831404

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 13139773

Country of ref document: US

122 Ep: pct application non-entry in european phase

Ref document number: 09831404

Country of ref document: EP

Kind code of ref document: A1