zoukankan      html  css  js  c++  java
  • PKI信息安全知识点

    1. 什么是X.509?

    X.509标准是ITU-T设计的PKI标准,他是为了解决X.500目录中的身份鉴别和访问控制问题设计的。

    2. 数字证书

    数字证书的意义在于回答公钥属于谁的问题,以帮助用户安全地获得对方的公开密钥。证书中应对公钥和公钥私有者信息,并由可信任的CA签署,即CA对这些信息进行数字签名。一张数字证书由证书内容、签名算法和算法结果组成。

    数字证书的结构如下:

    版本号 version

    序列号 serialNumber

    签名算法 signature

    有效日期 vaildity

    主体 subject

    主体公钥信息 subjectPublicKeyInfo

    颁发者唯一标识符 issuerUniqueID

    主体唯一标识符 subjectUniqueID

    扩展 extensions

    3. CRL基本原理和概念

    发布证书撤销信息的最基本思路就是:PKI系统中的CA机构将当前被撤销证书的标识(通常是证书序列号)集中到一个列表中,向PKI系统的所有用户公布。和签发证书一样,为了防止伪造和篡改,CA需要对这个列表进行数字签名。

    • 使用CRL验证证书的有效性。验证CRL签名上的数字签名是否正确、当前是否处于有效期。
    • 构造被撤销证书的证书序列号列表。对于不同的CRL机制,有着不同的方法来构造被撤销证书的信息列表。对于基本的CRL机制,从每一个单独的CRL文件就能够得到完整的、当前被撤销证书的证书序列号列表。
    • 检查证书是否已经被撤销。检查被撤销证书的证书序列号列表,查看验证的证书序列号是否在其中。

    CRL结构:

    CertificateList:: = Sequence{

    tbaCertList   TBSCertList,

    signatureAlgorithm   AlgorithmIdentifier,

    signatureValue  BIT STRING
    }

    其中tbaCertList又分为:

    TBSCertList::=SEQUENCE{
    signature             AlgorithmIdentifier,

    Issuer                   Name,

    thisUpdate           Time,

    nextUpdate         Time OPTIONAL

    revokedCertificates SEQUENCE OF SEQUENCE{

    userCertificate CertificateSerialNumber,

    revocationDate Time,

    crlEntryExtions Extensions  optional
    }

    crlExtensions [0]EXPLICIT Extionsions OPTIONALS

    }

    其中revocationCertificates是CRL最有意义的一部分,对于每一个被撤销的证书,CRL中给出证书序列号,和证书撤销时间。证书撤销时间一定早于CRL更新时间。

     

    4. 数字签名

    数字签名就是非对称密钥和数字摘要技术的应用。

    数字签名就是附加在数字单元上的一些数据。这种数据或变换允许数据单元的接受者用以确认数据单元的来源和数据单元的完整性并保护数据,防止被人进行伪造。

    发送方用特殊的hash算法,由明文中产生固定长度的【摘要】,然后利用自己的私钥对形成的摘要进行加密,这里加密后的数据就是数字签名。

    验证:接受方利用发送方的公钥解密被加密的摘要得到结果A,然后对明文也进行hash操作产生摘要B.最后,把A和B作比较。此方式既可以保证发送方的身份正确性,又可以保证数据在传输过程中不会被篡改。

    5.数字信封加密解密原理

    数字信封则采用密码技术保证了只有规定的接收人才能阅读信息的内容。

    数字信封中采用了单钥加密体制和公钥密码体制。信息发送者首先利用随机产生的【对称密码】加密信息(因为非对称加密技术的速度比较慢),再利用接收方的【公钥】加密对称密码,被公钥加密后的对称密钥被称之为数字信封。在传递信息时,信息接收方要解密信息时,必须先用自己的私钥解密数字信封,得到对称密码,才能利用对称密码解密所得到的信息。

    数字信封既发挥了对称加密算法速度快、安全性好的优点,又发挥了非对称加密算法密钥管理方便的优点。

    6. 常见的加密算法:

    对称加密算法:DES,3DES,AES

    非对称加密算法:RSA/ECC/SM2

    摘要算法:MD5,sha1,sha256

    填充算法:pkcs7填充。填充字符串由一个字节序列组成,每个字节填充该字节序列的长度

    数据: FF FF FF FF FF FF FF FF FF

    PKCS7 填充: FF FF FF FF FF FF FF FF FF 07 07 07 07 07 07 07

    7. 了解ASN.1编码规则:BER、DER

    基本编码规则(BER):对相同的数据可以有多种编码格式,比如长字节型,短字节型,不定长型。

    区分编码规则(DER):DER是BER的子集,和BER相比,它的编码格式只有固定一种,比如boolean变量,在BER中可以是0-255中任意一个,在DER中只能是1;

    8. 国际标准PKCS系列(如PKCS#7,PKCS#10,PKCS#12)

    PKCS#7:密码消息语法标准。PKCS#7为使用密码算法的数据规定了通用语法,比如数字签名和数字信封。PKCS#7提供了许多格式选项,包括未加密或签名的格式化消息、已封装(加密)消息、已签名消息和既经过签名又经过加密的消息

    signedData

    SignedData ::= SEQUENCE {

         version Version,

         digestAlgorithms DigestAlgorithmIdentifiers,

         contentInfo ContentInfo,

         certificates

            [0] IMPLICIT ExtendedCertificatesAndCertificates

              OPTIONAL,

         crls

           [1] IMPLICIT CertificateRevocationLists OPTIONAL,

         signerInfos SignerInfos }

    signerinfo type

    SignerInfo ::= SEQUENCE {

         version Version,

         issuerAndSerialNumber IssuerAndSerialNumber,

         digestAlgorithm DigestAlgorithmIdentifier,

         authenticatedAttributes

           [0] IMPLICIT Attributes OPTIONAL,

         digestEncryptionAlgorithm

           DigestEncryptionAlgorithmIdentifier,

         encryptedDigest EncryptedDigest,

         unauthenticatedAttributes

           [1] IMPLICIT Attributes OPTIONAL }

     

     

    EnvelopedData type

    EnvelopedData ::= SEQUENCE {

         version Version,

         recipientInfos RecipientInfos,

         encryptedContentInfo EncryptedContentInfo }

     

       RecipientInfos ::= SET OF RecipientInfo

     

       EncryptedContentInfo ::= SEQUENCE {

         contentType ContentType,

         contentEncryptionAlgorithm

           ContentEncryptionAlgorithmIdentifier,

         encryptedContent

           [0] IMPLICIT EncryptedContent OPTIONAL }

     

    PKCS#10:证书请求语法标准。PKCS#10定义了证书请求的语法。证书请求包含了一个唯一识别名、公钥和可选的一组属性,它们一起被请求证书的实体签名(证书管理协议中的PKIX证书请求消息就是一个PKCS#10)。

    CertificationRequest ::= SEQUENCE {

            certificationRequestInfo CertificationRequestInfo,

            signatureAlgorithm AlgorithmIdentifier{{ SignatureAlgorithms }},

            signature          BIT STRING

       }

     

       AlgorithmIdentifier {ALGORITHM:IOSet } ::= SEQUENCE {

            algorithm          ALGORITHM.&id({IOSet}),

            parameters         ALGORITHM.&Type({IOSet}{@algorithm}) OPTIONAL

       }

     

       SignatureAlgorithms ALGORITHM ::= {

            ... -- add any locally defined algorithms here -- }

    PKCS#12:个人信息交换语法标准。PKCS#12定义了个人身份信息(包括私钥、证书、各种秘密和扩展字段)的格式。PKCS#12有助于传输证书及对应的私钥,于是用户可以在不同设备间移动他们的个人身份信息。

    9.什么是RFC5280?

    RFC5280是X.509公钥基础设施证书和证书撤销列表的的配置文件。

    10. 什么是LDAP

    LDAP是Lightweight Directory Access Protocol的缩写,中文名是轻量目录访问协议。

    首先来谈一下目录服务,目录服务就是按照树状存储信息的模式。 LDAP的结构用树来表示,可以很快的查询结果,但是写入数据很慢。LDAP是一种开放Internet标准,LDAP协议是跨平台的 的Interent协议 它是基于X.500标准的, 与X.500不同,LDAP支持TCP/IP(即可以分布式部署)。

    11.什么是HTTPS以及SSL?

    超文本传输协议HTTP协议被用于在Web浏览器和网站服务器之间传递信息。HTTP协议以明文方式发送内容,不提供任何方式的数据加密,如果攻击者截取了Web浏览器和网站服务器之间的传输报文,就可以直接读懂其中的信息,因此HTTP协议不适合传输一些敏感信息,比如信用卡号、密码等。

    为了解决HTTP协议的这一缺陷,需要使用另一种协议:安全套接字层超文本传输协议HTTPS。为了数据传输的安全,HTTPS在HTTP的基础上加入了SSL协议,SSL依靠证书来验证服务器的身份,并为浏览器和服务器之间的通信加密。

    HTTPS和HTTP的区别主要为以下四点:

    一、https协议需要到ca申请证书,一般免费证书很少,需要交费。

    二、http是超文本传输协议,信息是明文传输,https 则是具有安全性的ssl加密传输协议。

    三、http和https使用的是完全不同的连接方式,用的端口也不一样,前者是80,后者是443。

    四、http的连接很简单,是无状态的;HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议,比http协议安全。

    总的来说HTTPS是HTTP基于SSL(或者TLS)的一个数据传输协议。

    SSL:

    协议介绍:

    1.SSL记录协议(SSL Record Protocol):它建立在可靠的传输协议(如TCP)之上,为高层协议提供数据封装、压缩、加密等基本功能的支持。

    2.SSL握手协议(SSL Handshake Protocol):它建立在SSL记录协议之上,用于在实际的数据传输开始前,通讯双方进行身份认证、协商加密算法、交换加密密钥等。

    SSL协议提供的服务主要有:

    1.认证用户和服务器,确保数据发送到正确的客户机和服务器。

    2.加密数据以防止数据被中途窃取

    3.维护数据的完整性,确保数据在传输过程中不被改变。

    SSL握手过程:

    ① 客户端的浏览器向服务器传送客户端SSL协议的版本号,加密算法的种类,产生的随机数,以及其他服务器和客户端通讯所需要的各种信息。

    ② 服务器向客户端传送SSL协议的版本号,加密算法的种类,随机数以及其他信息,同时服务器还将自己的证书发送给客户端。

    ③ 客户端利用服务器传过来的信息验证服务器的合法性,服务器的合法性包括:证书是否过期,发行服务器证书的CA是否可靠,发行者证书的公钥能否正确解开服务器证书的“发行者数字签名”,服务器证书上域名是否和服务器的实际域名相匹配。如果合法性验证没有通过,通讯将断开,如果合法性验证通过,将继续进行第四步。

    ④ 客户端随机产生一个用于后面通讯的对称密码,然后用服务器的公钥对其加密,然后将加密后的“预主密码”传递给服务器。

    ⑤ 如果服务器要求客户的身份认证(在握手过程中可选),用户可以生成一个随机数然后对其进行数字签名,将这个含有签名的随机数和客户自己的证书以及加密过的“预主密码”一起传给服务器。

    ⑥ 如果服务器要求客户的身份认证,服务器必须检查客户证书和签名随机数的合法性,具体的合法验证过程包括:证书使用日期是否有有效,为客户提供证书的CA是否可靠,发行CA的公钥能够正确解开客户证书发行CA的数字签名,检查客户证书是否被废除。如果检验没有通过,通讯立刻中断,如果验证通过,服务器将用自己的私钥解开加密的预主密码,然后执行一系列的步骤来产生通讯密码(客户端也将通过同样的方法产生相同的主通讯密码)。

    ⑦ 服务器和客户端用相同的主密码即通讯密码,一个对称密钥用于SSL协议的安全数据通讯的加解密通讯。同时在SSL通讯过程中还要完成数据通讯的完整性,防止数据通讯中的任何变化。

    ⑧ 客户端向服务端发出消息,指明后面的数据通讯将使用步骤七中的主密码为对称密钥,同时通知服务器客户端的握手过程结束。

    ⑨ 服务器向客户端发出消息,指明后面的数据通讯将使用步骤七中主密码为对称密钥,同时通知客户端服务器的握手过程结束。

    ⑩ SSL的握手部分结束,SSL安全通道的数据通讯开始,客户和服务器开始使用相同的对称密钥进行数据通讯,同时校验数据的完整性。

    12.什么是KeyStore?

    Keytool是一个Java数据证书的管理工具 ,Keytool将密钥(key)和证书(certificates)存在一个称为keystore的文件中。

    keystore里,包含两种数据:

    1. 密钥实体(Key entity)——密钥(secret key)又或者是私钥和配对公钥(采用非对称加密)

    2. 可信任的证书实体(trusted certificate entries)——只包含公钥

    ailas(别名)每个keystore都关联这一个独一无二的alias,这个alias通常不区分大小写。

    13.证书发放流程是什么?

    1. 用户在RA 注册信息,RA审核通过后,签发证书请求。
    2. RA把用户信息传到CA,CA从KMC中取密钥对(一般密钥对由加密机生成)
    3. CA把用户信息和公约制成用户证书,并对证书签名。CA把自己的用户证书和用户的私钥通过SSL通路传递给RA。
    4. 用户从RA下载证书。

     

    14.常见的证书拓展有哪些

    参见RFC3280,常见的拓展有证书策略,证书用途,是否为CA.

     

    15.公钥基础设施的整体架构。

    主要是证书认证中心,证书持有者,依赖方。

    辅助组件还包括注册机构RA,资料库系统、密钥管理系统KM,OCSP服务器。

    16.密钥不落地原理:

    ca向浏览器发加密证书和私钥的时候,私钥不能明文传输,需要用签名证书的公钥保护,私钥在km中存储的时候也不能明文,要用km的主密钥保护所以加密机有个接口,把加密机主密钥,保护公钥就是签名证书公钥,和主密钥加密的私钥明文一起传到加密机中,加密机用主密钥解密然后用保护公钥加密再传出来

     

    17.什么是双证书体系,与单证书的不同?

    双证书分为签名证书和加密证书。用于签名的私钥应该有订户自己保管。加密密钥由KMC共同保管。同一用户的两个证书除了证书序列号、公钥信息、KEY Usage拓展、private key usage period拓展、CA签名签名结果不同之外,其他都是相同的。

  • 相关阅读:
    Python绘图工具Plotly的简单使用
    gitlab runner安装与使用
    Ubuntu16.04下postgresql-10
    gitlab汉化
    Ubuntu 16.04 安装Gitlab
    Ubuntu-18.04安装Docker
    微信公众平台消息接口开发 彩票查询
    微信开发高级群发接口
    微信公众平台消息接口开发 快递查询
    搭建个人wordpress博客(小白教程)
  • 原文地址:https://www.cnblogs.com/superfj/p/7112112.html
Copyright © 2011-2022 走看看