电子商务安全：第7章 电子商务安全协议.pptVIP

王先生要买李小姐的一处房产，他发给李小姐一个购买报价单及对他对银行的授权书的消息，要求银行如果李小姐同意按此价格出卖，则将钱划到李小姐的帐上。 但是王先生不想让银行看到报价，也不想让李小姐看到他的银行帐号信息。 此外，报价和支付是相连的、不可分割的，仅当李小姐同意他的报价，钱才会转移。 首先生成两条消息的摘要，将两个摘要连接起来，生成一个新的摘要（称为双重签名），然后用签发者的私有密钥加密，为了让接收者验证双重签名，还必须将另外一条消息的摘要一块传过去。 这样，任何一个消息的接收者都可以通过以下方法验证消息的真实性：生成消息摘要，将它和另外一个消息摘要连接起来，生成新的摘要，如果它与解密后的双重签名相等，就可以确定消息是真实的。因此，如果李小姐同意，它发一个消息给银行表示她同意，另外包括报价单的消息摘要，银行能验证王先生授权的真实性，用张先生的授权书生成的摘要和李小姐消息中的报价单的摘要验证双重签名。银行根据双重签名可以判定报价单的真实性，但却看不到报价单的内容。 SET的交易流程 持卡人注册（Cardholder registration）：持卡人必须在发送SET信息给特约商店之前向CA注册。 特约商店注册（Merchant registration）： 特约商店必须在它们和消费者与支付网关交换SET信息之前，向CA申请注册。 购买请求（Purchase request）：从消费者送出给特约商店的消息，包含给特约商店的OI与给银行的PI。 支付授权（Payment authorization）：在特约商店与支付网关之间的交换，可以对特定账户信用卡持卡人的采购做授权。 支付获得（Payment capture）：让特约商店可以从支付网关请求支支付项。 证书询问与状态（Certificate inquiry and status）：如果CA无法快速完成一个证书请求的处理，它会发送一个消息给持卡人或特约商店，表明要请求者稍后再做确认。而持卡人或特约商店会发送证书询问的消息，来确定证书请求的状态，如果请求得到批准就会接收到证书了。 采购询问（Purchase inquiry）：采购响应消息收到后，持卡人可以询问订单处理状态。 记录回复（Capture reversal）：特约商店可以更正在取得请求消息中的错误，如销售员输入错误的交易数量。 购买请求 在购买请求之前，持卡人已经完成浏览选定商品以及订购的工作。这些工作都还没有使用到SET协议。　 购买请求过程，由四个消息构成：初始请求、初始回应、购买请求、购买回应。　 为了传送SET消息到特约商店，持卡人必须要保留一份特约商店及支付网关的证书副本。消费者在初始请求的消息中要求申请证书，然后这个消息会送到特约商店。这个消息包括消费者所使用的信用卡的公司，也包含了由消费者指定的回应这组请求的一个ID。 支付网关则需要执行以下工作： ⑴ 核对所有的证书 ⑵ 将授权区块的数字信封解密，得到对称密钥，然后就可以对授权区块解密了 ⑶ 核对授权区块中的特约商店签名 ⑷ 对支付区块的数字信封解密，得到对称密钥后，可以再将支付区块解密 ⑸ 核对支付区块中的双重签名 ⑹ 核对从特约商店接收到的交易ID，是否和从消费者接收到的PI内交易ID吻合 ⑺ 向发卡银行请求并接受授权 SET协议的安全性分析 在ISO/IEC 10181系列中阐述了开放式信息系统的安全架构标准，共包含七个部分：鉴别、访问控制、抗抵赖性、机密性、完整性、安全跟踪与告警以及密钥管理等服务; 访问及安全跟踪告警两部份牵涉到企业安全政策与组织架构的程度较深，SET并没有针对它们给应用系统开发人员提出系统的指导原则； 关于密钥管理的部分，SET协议也没有说明该如何处理，也就是说，目前SET将上述三个部份留给应用系统开发人员自行处理。 ⑴ 鉴别安全 SET的鉴别工作必须依赖公开密钥的运作体系（public key infrastructure，PKI），使得系统是否能实际运作必须依赖整体大环境是否成熟而定，例如签证体系的建立等，这将导致系统建设成本的大幅提升。 2.SSL协议无法提供基于UDP应用的安全保护 SSL协议需要在握手之前建立TCP连接，因此不能对UDP应用进行保护。如果要兼顾UDP协议层之上的安全保护，可以采用IP层的安全解决方案。 3.SSL协议不能对抗通信流量分析 由于SSL只对应用数据进行保护，数据包的IP头和TCP头仍然暴露在外，通过检查没有加密的IP源和目的地址以及TCP端口号或者检查通信数据量，一个通信分析者依然可以揭示哪一方在使用什么服务，有时甚至揭露商业或私人关系的秘密。 4.进程中主密钥泄漏 除非SSL的工程实现大部分驻留在硬件中，否则主密钥将会存留在主机的主存储器中，这就意味着任何可以读取SSL