讲座-密码算法应用.ppt

密码算法应用,高文宇 gwy,2019/11/17,2,内容提要,对称加密与非对称加密数字信封 数字签名，消息签名 消息摘要 公钥基础设施数字证书 Email安全协议PGP 时间戳协议 信用卡安全交易协议SET,2019/11/17,3,对称与非对称加密,加解密速度 密钥交换的难度 所需密钥数,2019/11/17,4,数字信封,A发送方，B接收方 (1)A用对称加密算法加密明文PT，产生密文CT，所有密钥为K1 (2)A采用非对称加密算法用B的公钥K2加密K1，设结果为F(K1,K2) (3)A将密文CT和F(K1,K2)发送给B (4)B收到CT和F(K1,K2) (5)B采用非对称加密算法用自己的私钥K3解密F(K1,K2)，得到K1 (6)B使用K1解密密文CT，得到明文PT,2019/11/17,5,数字签名,发送方A使用私钥加密，接收方B使用公钥解密,2019/11/17,6,数字签名的问题,使用非对称加密算法速度慢，密文大。因为发送方需要使用私钥加密整个明文消息，而明文消息可能很大，因此加密过程可能很慢,2019/11/17,7,消息签名（Message Signature）,发送方对消息摘要进行签名，然后发送出去,2019/11/17,8,签名鉴别（Signature Verify）,接收方收到签名的消息后，核对消息摘要，确保消息来自合法发送方，并且消息没有被篡改,2019/11/17,9,消息摘要,消息摘要（Message Digest）又称为散列（Hash），主要用于验证数据的完整性，即保证时消息在发送之后和接收之前没有被篡改 类似于各种校验，奇偶校验，循环冗余校验 实际应用中的消息摘要通常要占128位以上,2019/11/17,10,消息摘要的要求,（1）给定一个消息，应很容易求出消息摘要 （2）给定消息摘要，应该很难求出原来的消息 （3）给定两个消息，求出的消息摘要应该不同。因此通常的消息摘要的长度都在128位以上。,2019/11/17,11,非对称加密算法的问题,公钥交换时同样会受到“中间人攻击”,2019/11/17,12,问题,非对称加密是很好的解决方案，但是也存在未能解决的问题，就是双方如何交换公钥？如果公开交换，这容易在公钥上进行中间人攻击 事实上，密钥交换是设计任何计算机加密方案时最大的难题，解决的办法就是数字证书（Digital Certificates）,2019/11/17,13,数字证书,数字证书其实就是一个小的计算机文件，其作用类似于我们的身份证、护照,2019/11/17,14,生成数字证书,证书生成步骤： （1）密钥生成：用户生成一对公、私钥 （2）注册：用户将生成的私钥及相关信息提交给注册机构进行注册 （3）验证：注册机构验证用户信息及确保用户拥有对应的私钥 （4）证书生成：证书机构生成证书后通过Email通知或发送给用户,2019/11/17,15,注册机构如何确保用户拥有对应的私钥,（1）注册机构要求用户用私钥对证书请求进行数字签名。 （2）注册机构生成随机挑战，并用用户的公钥加密，要求用户解密数字挑战。 （3）注册机构对用户生成一个哑证书，用用户的公钥加密，然后发给用户，用户需要解密后才能获得明文证书。,2019/11/17,16,为何信任数字证书,因为： （1）证书机构对证书用自己的私钥进行了签名。 （2）其他收到该证书的用户可以用证书机构的公钥来验证证书是权威的证书机构颁发的，由于权威证书机构是可信任的，因此拥有该证书的用户也是可信任的。,2019/11/17,17,CA如何签名数字证书,证书机构用自己的私钥签名了数字证书，意味着承诺：“我已经对这个证书进行了签名，保证是这个用户持有指定的公钥，请相信我”。 签名方法：在向用户签发数字证书前，CA首先要对证书的所有字段计算一个消息摘要，然后用CA的私钥加密消息摘要，构成CA的数字签名。然后CA将计算的数字签名作为数字证书的最后一个字段插入。,2019/11/17,18,CA签名数字证书,CA,2019/11/17,19,验证CA的数字签名,CA验证数字证书,2019/11/17,20,如何验证数字证书,用户验证数字证书的步骤： （1）用户将数字证书中除最后一个字段外的所有字段输入消息摘要算法（CA在证书中指定了签名所有算法）。 （2）消息摘要算法计算出上述消息摘要，记为MD1。 （3）用户从证书中取出CA的数字签名（即证书的最后一个字段） （4）用户用CA的公钥解密签名，得到另一个消息摘要，记为MD2。 （5）用户比较MD1和MD2，若相等，则可以肯定数字证书是CA用其私钥签名的，否则用户不信任该证书，拒绝。,2019/11/17,21,Email安全性 PGP,Pretty Good Privacy 简单易用、安全免费，包括文档和源代码，因此广为使用，比PEM更普及。,2019/11/17,22,PGP工作原理,（1）数字签名 使用SHA-1算法生成电子邮件消息的消息摘要，然后用发送方的私钥加密消息摘要，形成数字签名 （2）压缩 使用ZIP算法压缩电子邮件消息和数字签名 （3）加密 使用IDEA算法（使用对称密钥）加密压缩后的信息 （4）数字信封 用接收方的公钥加密第（3）步中使用的对称密钥 （5）64进制编码,2019/11/17,23,PGP实践,PGP加密软件是美国Network Associate Inc. 公司开发的免费软件，可从,2019/11/17,24,时间戳协议,需求：在一些场合，一份重要的文件需要包含时间因素，因此需要提供权威的、（与原始文件）不可分割的、防篡改的时间标记。 时间戳协议（TSP），时间戳机构（TSA） TSP是一个简单的请求/响应协议，与HTTP类似，主要用于为用户提供第三方的时间认证。,2019/11/17,25,TSP的原理,（1）计算消息摘要。客户机对原消息进行消息摘要。 （2）请求时间戳。客户机将消息摘要发送给TSA，请求时间戳。 （3）时间戳响应。TSA将收到的消息摘要与当时的时间连接起来，并用自己的私钥签名，然后返回给客户机。,2019/11/17,26,SET- Security Electronic Transaction,主要是为了解决用户、商家和银行之间通过信用卡支付的交易而设计的，以保证支付信息的机密和支付过程的完整。 SET中的核心技术包括公钥加密、数字签名、数字信封、安全证书等。 是一个安全协议的集合。,2019/11/17,27,SET的设计目标,为支付/订购信息提供机密性。 通信信息的完整性。 鉴证持卡者是否是信用卡账户的合法用户。 持卡用户需要确认能与之进行安全交易的商家的身份。 采用最好的安全策略和系统设计技术来保护电子商务交易中的所有合法方。 安全性应不依赖于传运输层安全机制，但又可以充分利用传输层的安全服务。 协议应该独立于硬件平台、操作系统和WEB软件。,2019/11/17,28,SET 参与者,2019/11/17,29,利用SET协议的典型交易事件序列,申领信用卡。 持卡用户获得证书。 商家获得证书。 持卡用户订购商品。 用户对商家的身份认证。 用户发送订购和支付信息。 商家请求支付认可。 商家确认订购。 供货。 商家请求支付。,2019/11/17,30,安全交易中的两个关键问题,（1）客户定购商品，必须向商家发送定购信息和支付信息，其中支付信息包含信用卡号等私人信息。因此SET协议应该能够防止这些信息被商家恶意盗用。 （2）定购信息和支付信息要紧密绑定，不能被分割用于非法目的。,2019/11/17,31,购物请求的交互过程,第1步：启动请求 向商家请求商家的证书和支付网关的证书。 第2步：启动响应 包括商家的签名证书以及支付网关的密钥交换证书； 持卡用户对商家提供的证书和支付网关证书进行验证，验证通过证书中CA签名来进行。 第3步：购物请求 与支付相关的信息； 与订购有关的信息； 持卡用户的证书。 第4步：购物响应 包含相应的交易号码用于确认订购。,2019/11/17,32,购物请求消息,与支付相关的信息：与支付相关的信息将被商家转发给支付网关。 支付信息（PI）； 双向签名（DS），是在PI和OI上计算的散列值，并使用用户的私有签名密钥进行签名； 订购信息（OI）的报文摘要OIMD，支付网关需要OIMD来验证双向签名； 数字信封，是用支付网关的公开密钥KUb对对称密钥Ks进行加密而形成的。 与订购有关的信息 ：是商家处理交易所必需的信息。 订购信息OI，OI是明文发送的； 双向签名（DS），是在PI和OI上计算的散列值，并使用用户的私有签名密钥进行签名； 支付信息PI报文摘要（PIMD），用于商家进行双向签名的验证。 持卡用户的证书。 包含了持卡用户的签名公开密钥，商家和支付网关都需要使用该密钥来进行签名的验证。,2019/11/17,33,持卡人生成“购物请求”的过程,2019/11/17,34,商家 对“购物请求”的验证,2019/11/17,35,商家 对“购物请求”的验证,通过持卡用户的CA签名来验证持卡用户的证书。 使用持卡用户的签名公开密钥来验证双向签名，以验证订购信息的完整性，即在传输过程中没有被篡改。 处理订购信息，并将支付信息转交给支付网关进行支付认可。 向卡用户发送“购物响应”消息报文。,2019/11/17,36,付款授权,付款授权发生在商家将付款细节发送给付款网关时，付款网关验证这些细节并批准付款，保证商家收到付款 商家向支付网关发送一个“授权请求” 报文，包括： （1）购物相关信息，（2）授权相关信息，（3）证书 接收到“认可请求” 后，支付网关完成以下操作： 验证所有的证书。 对认可数据块的数字信封进行解密，获得一次性对称密钥，然后解密认可数据块。 验证认可数据块中商家的签名。 对支付数据块的数字信封进行解密，获得一次性对称密钥，然后解密支付数据块。 验证支付数据块中的双向签名。 验证从商家提交的交易ID是否与用户PI中的交易ID匹配。 向发