标签：数据安全
数据传输过程中的安全隐患
数据机密性明文传输 就像一个传递一个明信片一样在传递过程中所有中转站都可以看到。
数据的完整性数据在传输时中间人有可能将原数据做修改然后再将修改后的数据传给接收者。
身份验证在数据交易时防止交易对象是虚假的。例如假的工商银行页面。
一、数据机密性
利用数学算法将明文内容 转换成 模糊的数据。接收者再利用相同的算法将模糊的内容 转换成 明文内容。加密本身就是一种转换规则。它可以将 输出的数据 转换成 一些杂乱无章的 数据。
转换前的数据称为plaintext 转换后的数据称为ciphertext
加密就是利用 固定的 转换规则 将 plaintext ----> ciphertext
解密就是利用 相同的 转换规则 将 ciphertext ----> plaintext
由于 转换规则(数学算法) 比较少所以利用“密钥”系数按照转换规则进行加密或解密。
因此 互联网中 转换规则 都是公开的而“密钥”系统是私密的。
对称加密加密与解密使用同一个“密钥”。它的速度快对CPU的压力小可适用于对大数据加密。
由于计算机的通迅对象很多此时需要建立多个"密钥"对应不同的通迅所以"密钥管理" 就比较复杂(无法有效的"密钥管理")而且 A 与 B 的 密钥如何传输。
单向加密(hash)
1、输入相同输出必然相同
2、输入的微小改变将会引起结果的巨大改变。雪崩效应
3、定长输出无论原始数据多大结果长度都相同
4、不可逆无法通过特征码还原原有数据
二、数据完整性(防篡改)
解决办法利用单向加密算法提取数据特征码。
例如A: plaintext:footprint --> B: plaintext:footprint
B: 收到后重新计算"特征码"比较两个"特征码"是否相同来判断原数据有无变化。
引发的问题中间人攻击即中间人修改明文然后把修改后的明文再计算"特征码"然后把明文与"特征码"一块发给接收者。
解决办法
A: plaintext:(footprint) 发送方将"特征码"加密然后发送
B: 接收方收到加密后的"特征码"和明文后解密"特征码"然后验证即可。
引发问题 A 与 B 的 密钥如何传输。
解决办法Internet Key Change
Diffie-Hellman 协议 它就是一种 IKE的算法
原理
A与B通迅要先选择相同的 P(大素数) g(生成系数)
A在本机内部选择一个随机数x B在本机内部选择一个随机数y
A将 g^x%P 的结果传输给B 而B将 g^y%P的结果传输给A
然后A将收到的(g^y%P)再计算(g^y%P)^x
然后B将收到的(g^x%P)再计算(g^x%P)^y
最终A与B可以计算出相同的结果 g^xy%P 该结果即为密钥。
A、B双方可以使用一个DH算法的软件来管理密钥而且密钥可以每隔一段时间更换从而保证安全性实现了密钥的有效管理。而且利用上述方法也实现了防篡改(数据的完整性)
以上过程通迅双方已经不需要事先约定密钥使用DH算法的软件管理密钥即可实现数据的完整性。
但它又引出了一个新的问题原始方法是通迅双方在通迅前事先约定密钥这样双方也可以验证对方的身份。但如果使用IKE双方不再需要事先约定密钥在通迅前双方都不知道密钥而是由DH算法的软件来计算密钥的那么身份验证又如何实现
三、身份验证
非对称加密算法密钥是成对出现的即公钥(public key) 和私钥 (secret key或private key)
公钥是私钥的一部分是从私钥中提取出来的。 (一般的私钥都很长512bit 768bit 1024bit 2048bit 4096bit等)。用公钥加密的数据必须用私钥解密。 当然用私钥加密的数据也必须用对应的公钥进行解密。
如果发送方用接收方的公钥加密只有接收方使用自己的私钥才可以解密就实现了数据的机密性。
如果发送方用自己的私钥进行加密接收方用"发送方"的公钥可以成功解密就说明了公钥、私钥的对称性就实现了身份验证功能。
由于公钥、私钥的复杂性决定了它的算法占用CPU资源速度较慢只适合加密少量的数据。它的速度比对称加密算法慢千倍。所以它经常用来做身份验证与数字签名
例如A在发送数据时把明文数据使用单向加密算法提取"特征码"然后利用自己A的私钥对"特征码"进行加密然后把加密后的"特征码"与明文数据一起发送给B当B收到之后使用A的公钥对"特征码"解密如果解密成功证明该数据一定是A发送的即完成了身份验证的功能然后B再次使用单向加密算法对收到的"明文数据"提取特征码最后比较两个"特征码"是否相同如果相同就说明原始数据没有被篡改过实现了数据的完整性。
以上过程中公钥决定了关键的作用。
但也会引出一个新的问题如何确保对方的公钥是对方的呢
解决办法 借助第三方机构---发证机构。
四、第三方机构(certificate authority)
A在自己的机器上生成公钥、私钥对然后A将公钥提交给第三方机构由第三方机构为该公钥做公证(证明它的真实性和有效性)。第三方机构为该公钥做一个数字证书证书中包含A端的个人信息、公钥信息、以及发证机构再次使用单向加密算法抽取该证书的特征码并利用发证机构自己的私钥对特征码加密把加密后的特征码也添加到用户A的证书中。
当B要与A通迅时A会事先将自己的证书发送给BB收到A的证书后它在信任"第三方证书颁发机构"的情况下信任A的证书信任A的公钥。
B如何信任A的证书呢
B必须信任"第三方证书颁发机构"B必须有"第三方证书颁发机构"的证书。当B拥有了"发证机构"的证书后就拥有了"发证机构"的公钥就可以利用"发证机构"的公钥解密A证书中的"特征码"如果解密成功就证明该证书一定是"发证机构"颁发的也就证明了A的公钥是真实、有效的。
引入一个新的问题如何获得"发证机构"的公钥如何获取" 发证机构"的证书"发证机构"的证书又是谁颁发的呢
证书颁发机构它有它自己自签名的证书。用户可以到证书颁发机构的实体店用一个U盘将证书颁发机构的证书复制回来导入到自己的计算机上。当然证书颁发机构也可以上门服务但证书颁发机构的服务是收费的而且费用较高。
在通迅的过程中只要拿到单方向的证书就可以保证数据的完整性和身份验证。例用户访问淘宝时只要用户拿到淘宝的证书即可完成身份验证及保证数据的完整性。普通情况下淘宝是不需要验证用户身份单向验证即可。当然只有用户发起交易时淘宝才需要验证用户的身份如何实现呢利用支付宝这个中间平台支付宝仅仅可以保证用户交易不能随意撤消。那么用户的钱又是如何转账到支持宝呢这个验证用户身份的工作又移交给了银行。银行又是如何验证用户身份的呢银行要求转账时使用U盾或加密盾或使用手机信息二次验证等。其实U盾中存储的就是一个银行的证书而且使用U盾时还需要用密码验证、确认。
数据的机密性如何保证呢
数据加密使用对称加密。通信双方在通迅之前相互获取对方的证书、公钥然后双方使用IKE协议 DH算法的软件生成 (对称)加密的密钥。 发送方首先使用单向加密将明文数据提取特征码然后利用自己的私钥对"特征码"加密最后发送方再利用DH算法产生的对称密钥 将 原明文数据与加密后的"特征码" 一块再加密最终将加密后的内容发送给接收方。
当接收方收到之后首先利用DH算法产生的对称密钥将接收到的数据块解密。然后再用发送方的公钥对"特征码"部分解密如果解密成功说明该数据一定是发送方发的而不是冒名发送完成了身份验证然后再用单向加密算法对明文数据提取"特征码"最后比较这两个"特征码"如果相同就说明数据在传输过程中没有被篡改过从而保证了数据的完整性。
以上的过程中虽然实现了身份验证、加密、数据完整性但DH算法还是比较复杂的还有更简单的方法实现。
就是发送方在对整个数据加密时使用随机数加密然后再用接收方的公钥将随机数加密附加在数据上一起传递给接收方。接收方收到之后先用自己的私钥将随机数密钥解密出来然后再用随机数密钥解密整个数据块然后再用发送方的公钥解密特征码然后自己再用单向加密算法对明文数据提取特征码最后比较两个特征码是否相同完成整个通迅。
实现加密、数字签名、数据完整性机制、数字信封、双重数字签名等并提供应用程序接口的一套数据安全系统称为PKI。
PKI的基本组成完整的PKI系统必须具有权威认证机构(CA)、数字证书库、密钥备份及恢复系统、证书作废系统、应用接口API等基本构成部分构建PKI也将围绕着这五大系统来着手构建。
CA证书颁发机构有根CA、从属CA。根CA只负责派发分支机构。CA要负责证书登记-->证书分发-->证书吊销-->证书延期-->证书审计
如果私钥丢失就会引发一些问题。此时就可以声明证书失效。另外为了保证私钥的安全性需要对私钥设置密码。使用CRL 证书吊销列表来声明哪些证书已经失效。
常见的证书格式X509的证书格式是标准格式、pkcs12。
x509中包含公钥及其有效期限、证书的合法拥有者、证书该如何被使用、CA的信息、使用CA的私钥进行签名的校验码。
PKI的实现
1、TLS/SSL 使用x509的证书
2、OpenGPG
这两种应用的区别 它们实现证书管理机制不同、信息关系的传递方法不同。
TLS/SSL是如何工作的
Netscape 网景公司 为了实现安全通迅在TCP 层与应用层之间加了一个SSL层。它仅仅是一个库。
这样可以使应用层的明文协议调用这个SSL库封装后再交给TCP层就实现了安全传输(https 、ftps、pop3s、imap4s等)。
SSL ( Secure Socket Layer) SSL v1 SSL v2 SSL v3 目前应用是v2 与 v3
由于 SSL技术是网景公司开发的技术所以国际标准化组织为了进一步的开放性开发了TLS (Transport Layer Security)目前是TLS v1 (相当于SSL v3)
TLS很像是在传输层实现的。
以http(tcp)为例说明https的工作过程。 建立会话前 需要三次握手握手后不直接通迅而是双方互相协商建立SSL会话(选择SSL的版本或TLS v1、选择加密算法)、然后Server端会将自己的证书发给客户端client收到后要验证证书验证证书的真实性和有效性如果成功就取得了Server的公钥。然后client生成一个会话密钥(对称加密方式此时并没有使用IKE密钥交换而是使用随机数随机生成一个对称密钥)然后client使用Server端的公钥将会话密钥加密并传输给Server端然后Server端使用自己的私钥解密会话密钥并使用会话密钥将数据加密最终传输给客户端。
整个非对称式加密本身可以实现加密数据、身份验证(和 密钥交换)
五、加密算法
对称加密的算法有DES(由NAS征集加密算法时IBM公司提供的Data Encryption Standard)。 DES使用56位的密钥到2000年以后人们使用性能较好的计算机暴力破解了DES至此DES不再安全。当然人们又开发了3DES。它是现今比较流行的加密算法。但它并不是最可信的加密算法所以美国国家安全局再次征集加密算法就出来了AES (Advanced Encryption Standard)。标准的AES是128bit的一些变种的AES算法出来了AES 192、AES 256、AES 512等当然密钥越长越安全但速度越慢。当然还有 Blowfish 、RC也是对称加密算法。
单向加密MD4、MD5、SHA1、SHA192、SHA256、SHA384 等这些不是密钥长度是输出长度。
CRC-32 冗余校验它仅仅是一种校验算法不提供安全性。
非对称加密
可以实现身份认证(数字签名)和数据加密也可以实现密钥交换。常见的算法有RSA(是三个人名的缩写、也是公司名、也是加密算法名)它可以加密、签名DSA(只能签名)ElGamal (商业算法)等
本文只介绍数据安全的理论如何利用openssl 和 openGpG实现数据安全请关注后其文档
本文出自 “11462293” 博客，请务必保留此出处http://11472293.blog.51cto.com/11462293/1796617
Data transmission security theory
标签：数据安全
原文地址：http://11472293.blog.51cto.com/11462293/1796617
