• 对称加密与非对称加密


    程序代码中我用的是对称加密。 (加密、解密都是一个密钥)

    RPC中buffer格式如下:

    [socket bufferLen]  + [MD5 result]     +  {[business bufLen]   +  [business  cmdCode] +  [business  buf]}
     4Bytes                32Bytes               4Bytes                 4Bytes                 Unknow
     
    - 密钥长度可以自己定义 (如果有性能要求的话,不需要太大,我们定义的是6bytes)
    - [MD5 result] 是对 {花括号中的数据 + [密钥]} 进行MD5的值
    - 接收方,知道我的密钥,先把{花括号中的数据 + [密钥]}做MD5得到的值,和[MD5 result]做对比,
        * 如果错误则记录 + 抛弃此信息
        * 如果正确,则做正常业务
    
    

    非对称加密与OpenSSL via pannengzhi

    随着个人隐私越来越受重视, HTTPS也渐渐的流行起来, 甚至有许多网站都做到了全站HTTPS,
    然而这种加密和信任机制也不断遭遇挑战,比如戴尔根证书携带私钥,Xboxlive证书私钥泻露,
    还有前一段时间的沃通错误颁发Github根域名SSL证书事件. 因此本文从非对称加密说起,
    介绍了证书的签证流程, 并且通过openssl的命令行工具对这些过程都转化为相对具体的命令,
    也算是一个温故知新的简要记录吧.

    1.前言

    一般来说,常见的数字加密方式都可以分为两类,即对称加密和非对称加密. 对于对称加密来说,
    加密和解密用的是同一个密钥, 加密方法有AES,DES,RC4,BlowFish等; 对应的, 非对称加密在
    加密和解密时, 用的是不同的密钥, 分别称为公钥或私钥. 非对称加密的加密方法有RSA, DSA,
    Diffie-Hellman等.

    OpenSSL是一个开源项目,为传输层安全(TLS)和安全套接字(SSL)协议提供了比较完整的实现,
    同时也致力于将自身打造为一个通用的密码学工具集. 其中包括:

    • libssl : 提供了SSL(包括SSLv3)和TLS的服务器端以及客户端的实现.
    • libcrypto : 通用的密码学库以及对X.509的支持
    • openssl : 一个多功能的命令行工具

    本文主要使用openssl的命令行工具来示例非对称加密的流程, 如果有兴趣的话,也可以用其SDK
    来实现更具体的操作.

    2.加解密过程

    2.1创建公私钥对

    首先用openssl生成私钥:

    openssl genrsa -out private.pem 1024

    当然为了更加安全,可以在生成私钥的时候同时指定密码, 这样即使不小心泻露了私钥,也能增加别人的盗用难度:

    openssl genrsa -aes256 -passout stdin -out private.pem 1024
    openssl genrsa -aes256 -passout file:passwd.txt  -out private.pem 1024
    openssl genrsa -aes256 -passout pass:my_password -out private.pem 1024
    

    其中 -passout 指定密码的输入方式,可以分别是stdin,从文件中读取或者紧接着pass:后面输入.
    有了私钥,便可以从其中提取出公钥:

    openssl rsa -in private.pem -pubout -out public.pem

    2.2用公私钥进行加解密

    在一次秘密的信息传输中, 我们首先通过可信的方式(比如面对面)将公钥告知对方, 对方发送机密信息的时候
    就可以用我们的公钥加密:

    openssl rsautl -encrypt -pubin -inkey public.pem -in file.txt -out file.txt.enc

    在发送的过程中即便泄露了文件,也无法查看文件的明文信息. 而我们收到密文后, 用私钥解密即可:

    openssl rsautl -decrypt -inkey private.pem -in file.txt.enc -out file.txt.dec

    2.2和对称加密协作

    虽然公私钥加密很好用, 但事实上非对称加密的缺点是加解密速度要远远慢于对称加密, 在某些极端情况下,
    甚至能比非对称加密慢上千倍. 另外由于RSA算法的工作机理, 如果密钥是n比特的,那么其加密的信息容量就
    不能大于(n-11)比特. 因此对于大文件的加密传输, 通常还是使用对称加密的方式, 例如

    openssl rand -base64 128 -out aeskey.txt
    openssl enc -aes-256-cbc -salt -in file.txt -out file.txt.aesenc -pass file:aeskey.txt
    openssl enc -d -aes-256-cbc -in file.txt.aesenc -out file.txt.aesdec -pass file:aeskey.txt
    

    其中aeskey.txt是我们随机生成密码文件, 并且用其可以对大文件进行对称的加解密, 在实际中,
    通常还会将密码文件用公私钥加密的方式来发送给对方. 值得一提的是,这也正是PGP的工作方式,

    加密解密

    3.证书

    对任一个体来说, 它都有公钥,私钥和证书. 其中私钥用来加密发出去的信息,公钥用来解密收到的信息,
    而证书则用来证明自己的身份. 一般来说,证书中包含自己的公钥以及额外的信息,如签发机构(CA, Certificate Authority),
    证书用途(比如适用的域名)和有效时间等. CA通常是个第三方的可信机构, 比如VeriSign, GeoTrust,
    DigiCert和沃通等, 当然也可以是未知的主体, 比如说自己.

    获得一张证书的流程通常是:

    • 1)用私钥生成证书签名请求(csr),
    • 2)将csr文件发送给CA,待其验证信息无误后,CA会用自己的私钥对其进行签名表示确认.

    3.1 生成证书签名请求

    证书签名请求(Certificate Signing Request)通常以.csr为后缀, 包含了请求方的公钥和主体的详细信息,
    如域名,公司名,国家,城市等信息, 其完整内容可以参考这里. 使用openssl也能很方便地生成csr:

    openssl req -new -key private.pem -out pppan.csr

    默认会在stdin中根据提示交互地输入主体信息,也可以通过 -config选项来从文件中读取.
    生成完之后可以通过:

    openssl req -in pppan.csr -noout -text

    来查看csr文件中的详细信息.

    3.2 CA对csr文件进行签名

    当CA收到csr文件并且对请求方的域名,公司等内容校验无误后,便可以对csr请求进行确认(签名),

    openssl req -x509 -newkey rsa:4096 -nodes -keyout cakey.pem -out cacert.pem -outform PEM
    openssl ca -config openssl-ca.cnf -policy SP -extensions SR -infiles pppan.csr -out pppan.crt
    

    虽然这不是重点, 但也稍微解释下这两个命令的意思吧. 第一个命令是CA一开始创建私钥和CA的证书,
    第二个命令表示对csr文件进行签名确认, 用-config指定自定义的配置文件, 如果不指定则默认为/usr/lib/ssl/openssl.cnf,
    SP和SR都是自定义于配置文件中的信息, 此外配置文件中还包括CA证书路径和私钥路径,以及对req的默认校验策略等,
    有兴趣的可以查看详细解释.

    另外值得一提的是, 我们用自己的私钥也可以生成证书, 并且也能用这个证书来对自己的csr进行签名,
    这通常称为自签名(self-signed), 上面CA生成的证书cacert.pem就是自签名的. 一般来说,
    如果是自己随便生成自签名证书, 通常会被认为是不可信的, 除非手动添加到对方的信任CA证书列表中.

    3.3查看和验证证书

    CA对csr进行签名后, 我们就能得到对应的证书, 这里是pppan.crt, 可以用openssl查看证书的详细信息:

    openssl x509 -noout -text -in pppan.crt

    可以看到具体的签发机构,签发时间和证书的有效时间等信息.
    可以用命令验证证书是否有效:

    openssl verify -CAfile Trusts.pem pppan.crt

    其中Trusts.pem是一系列所信任的证书集合,其中也包括了上述CA的证书cacert.pem

    4. 其他

    上面所有用到的证书及其组件,如公钥,私钥,csr等,其格式都是PEM的,这也是最常见的一种格式,
    可以用文本便及其打开,通常是以-----BEGIN XXX------开头, 以-----END XXX-----结束,
    中间的部分则是实际密钥的base64编码, 其二进制表示也称为DER格式, 两者可以用base64转化,
    因此都属于x509实现的证书格式.

    还有比较常见的证书格式,为PKCS7和PKCS12. 其中PKCS7是由JAVA使用的开放标准,并且也被
    Windows所支持, 其内是不包含私钥信息的; 而PKCS12则是一种非公开的标准,用来提供比PEM的
    纯文本格式更高的安全性, 这是Windows建议使用的格式, 其中可以包含私钥信息.

    不同格式的转换如下所示.

    PEM <-> DER:
    
    openssl x509 -in bar.pem -outform der -out bar.der
    openssl x509 -inform der -in foo.der -out foo.pem
    PEM <-> PKCS7:
    
    openssl crl2pkcs7 -nocrl -certfile foocert.pem -out foocert.p7b 
    openssl pkcs7 -in foocert.p7b  -print_certs -out barcert.pem  
    PEM <-> PKCS12:
    
    openssl pkcs12 -inkey private.key -in foocert.pem -export -out foocert.pfx
    openssl pkcs12 -in foocert.pfx -nodes -out barcert.pem 
    

    5. 后记

    当今我们使用最多的https本质上就是在http协议的基础上对传输内容进行了非对称的加密,
    当然实现过程多了很多复杂的交互, 感兴趣的可以去查看SSL和TLS协议. 我想说的是,
    这一切信任机制的基石是对于CA的信任, 如果说CA的私钥泻露,或者我们错误地信任了一个坏CA,
    那么https的隐私性也就不复存在了, 因为其可能对无效的csr进行签名, 从而使得https中间人攻击
    成为现实. 据说早在两年前伟大的防火墙就已经可以对https进行监听,敏感词识别和连接重置,
    后来因为某种原因才从大范围应用转为只对特殊对象使用,不过那是后话了.

    博客地址:

    http://pppan.net
    有价值炮灰-博客园
    欢迎交流,文章转载请注明出处.

    

  • 相关阅读:
    ARTS习惯(8)
    ARTS习惯(7)
    ARTS习惯(6)
    ARTS习惯(5)
    ARTS习惯(4)
    ARTS习惯(3)
    线程状态
    java线程同步
    数据库视图
    数据库事务
  • 原文地址:https://www.cnblogs.com/scotth/p/6366016.html
Copyright © 2020-2023  润新知