网络安全设计（一）

一、基础密码学
三种基本的加密函数：对称加密、非对称加密和单向哈希函数。
身份或隐蔽秘钥的泄露都是威胁安全最常见的形式。
1.密码学
密码学（Cryptography）是一门读取或编写密码报文的科学，是实现认证、完整性和机密性机制的基石。
    认证（authentication）：建立了信息的发送者和/或接受者的身份。在一些通信情况下，并不总是需要双方互相认证。
    完整性（integrity）：可以保证数据在传输过程中不被更改。
    机密性（confidentiality）：确保了只有数据的发送者和接受者才能够真正理解这些数据。
   1.1对称秘钥加密
   对称加密（Symmetric encryption），通常指秘密秘钥加密（secret key encryption），使用一个公共秘钥和同一个加密算法来加密和解密报文。
    • DES：对64位的报文块进行操作。该算法使用一些列步骤把64位输入变换成64位输出。标准方式使用64位秘钥，其中56位是随机选取的。其余8位是奇偶位（每一位对应56位随机值中的每个7位块）。
    • 3DES:使用64位数据块执行加密、解密和加密操作。可以使用一个、两个或三个不通的秘钥。
    • RC-4:该算法的秘钥长度可变，但是通常使用128位秘钥。作为商业机密收到保护。
    • IDEA:开发用来替代DES。它也对64位报文块进行操作，但是使用一个128位秘钥。它是获得了专利的算法，只有经过批准才能商用。
    • AES:Rijndael算法是一个对称块加密算法，它能够处理128位的数据块，使用128位、192位和256位3种不同的秘钥长度。Rijndael算法的内存需求非常低，所有很适合移动和无线环境。
注意：因为大多数对称秘钥算法已经设计为在迎检上实现，并对一次加密大量的数据做了优化，秘钥加密最常用语保证数据的机密性。秘钥加密面临如下挑战：
    • 经常改变秘钥以避免泄露秘钥的危险；
    • 安全地生成秘钥。
    • 安全地分配秘钥。
   1.2非对称秘钥
    非对称加密通常指公钥加密，可以使用相同算法或者不同但互补的算法来加密和恢复数据。非对称加密需要两个不相同却相关的秘钥值：一个公钥和一个私钥。
    公钥算法有几种常见的用途：
    • 数据完整性
    • 数据机密性
    • 发送方不可抵赖
    • 发送方认证
    可以使用公钥算法实现数据机密性和发送方认证。
    A和B要进行机密数据交换，则需要采取如下步骤：
    第1步：A和B都创建他们自己的公/私钥对。
    第2步：A和B交换他们的公钥。
    第3步：A写一个给B的报文，并使用B的公钥对报文进行加密。接着，A通过因特网向B发送经过加密的数据。
    第4步：B使用自己私钥解密报文。
    第5步：B写一个回复，用A的公钥加密该回复，并把经过加密的回复通过因特网发送给A。
    第6步：A使用自己的私钥来解密回复。
    因为只有B可以使用他的私钥解密报文，所以当A发送初始报文时，数据机密性得到了保证。因为要修改报文，恶意的攻击者又需要B的私钥，因此数据完整性也得到了保证。因为只有A知道自己的私钥，也只有她可以使用她的私钥修改或解密回复，回复的数据完整性和机密性得到了保证。
    但是这个交换不是非常安全，因为第三方容易假冒A并向B发送一条用B的公钥加密的报文，毕竟公钥很容易得到。确定是A发送了初始报文是重要的。
    如果A和B要进行认证数据交换，则必须采取如下步骤：
    第1步：A和B都创建他们的公/私钥对。
    第2步：A和B交换他们的公钥。
    第3步：A写一个给B的报文，并使用她的私钥对报文进行加密。接着，她通过因特网向B发送经过加密的数据，
    第4步：B使用A的公钥解密报文。
    第5步：B写一个回复，用他的私钥加密该回复，并把经过加密的回复通过因特网发送给A。
    第6步：A使用B的公钥来解密回复。
    因为只有B和A可以访问他们各自的私钥，确保了认证交换。因为B和A的密钥还没有泄露，以后不能否认发送了特定的报文，因此他们满足了不可抵赖的需求。这本身当然会引起对B和A诚实性的激烈争论，他们只要声明私钥已经泄露了就可以否认发送了报文。
    为了使用公钥加密来执行经过认证的交换以及确保数据完整性和机密性，需要进行双重加密。A首先使用B的公钥加密她给B的机密报文，然后再用她的私钥加密。任何人可以通过解密第一个报文来获得其密文，但是只有B能够用他的私钥解密该密文。
注意：非对称加密的一个关键问题是私钥必须保密。如果私钥泄露了，恶意的攻击者可以冒充你去发送和接收报文。
    公/私钥对的生成机制是复杂的，通过该机制生成两个非常大的随机数，其中一个为公钥，另一个为私钥。因为这些数字和它们的乘积必须符合严格的数学标准以保证每个公/私钥对的唯一性，生成这些数字需要性能相当高的处理器。
注意：使用任何数学标准都不能保证密钥对是唯一的。但是，数学方法保证了不生成弱密码。
    公钥加密算法受性能所限，很少用于保证数据机密性。公钥加密主要用于使用数字签名和密钥管理进行认证的应用。
   1.3.哈希函数
    哈希函数（hash function）接收一条任意长度的输入报文，输出定长代码。该定长代码就叫做原始输入报文的哈希或报文摘要（essage digest）。如果一个算法被认为适合于哈希函数的加密（即安全的），则它必须具有如下特征：
    • 函数必须是一致的，即相同的输入总是产生相同的输出；
    • 函数必须是单向的（即不可逆的），如果给定输出，则即使可能也很难确定输入报文的内容；
    • 函数的输出必须是随机的，或貌似随机的，以防备猜测；
    • 函数的输出必须是唯一的，及几乎不可能找到两个产生相同报文摘要的报文。
    单向哈希函数通常用来提供报文或文件的指纹（fingerprint）。哈希指纹非常像人的指纹，也是唯一的，从而提供了报文的完整性和可靠性。
    A和B想要保持他们的数据完整性，必须采用如下步骤：
    第1步：A写了一个报文，并把该报文作为一个单向哈希函数的输入。
    第2步：哈希函数的输出结果作为指纹附件加到发送给B的报文后面。
    第3步：B分离出报文和附加的指纹，并使用该报文作为A使用的同一个单向哈希函数的输入。
    第4步：如果哈希值匹配， B就可以确认报文没有被篡改。
    这个简单方法存在的问题是指指纹本身可能被篡改并易遭到中间人攻击。中间人攻击（man-in-thie-middle attack）指一个侦听被认为是安全的通信，并冒充发送方或接受方的实体。使用加密的哈希函数是使哈希函数更加安全的一个变体，其中算法的输入时一个共享密钥及原始报文。但是为了更有效把哈希函数作为指纹使用，可以将它们与公钥技术一期使用起来提供数字签名。
1.4数据签名
    数字签名（digital signature）是附加到文档后的加密的报文摘要，有时也称为数字指纹。数字签名确定了发送方身份和文档的完整性，它以公钥加密和单向安全哈希函数算法的结合为基础。
    要创建一个数字签名，B必须采取如下步骤：
    第1步：B创建一个公/私钥对。
    第2步：B把自己的公钥给A。
    第3步：B写一个给A的报文，并使用该文档作为单向哈希函数的输入。
    第4步：B用自己的私钥加密哈希算法的输出和报文摘要，生成数字签名。
    B发送给A的报文是文档和数字签名的组合。
    在接收方，A遵循下面这些步骤来证实报文的确来自B--即对数字签名进行验证。
    第1步：A把接收到的报文分离成原始文档和数字签名。
    第2步：A用B的公钥解密数字签名，生成原始的报文摘要。
    第3步：A把原始文档作为B使用的同一个哈希函数的输入，生成一个报文摘要。
    第4步：A比较两个报文摘要的一致性。
    如果A计算出的报文摘要和B的被解密的报文摘要一致，文档的完整性和发送方的认证就得到了证明。
    注意：为了确保安全性，最初的公钥交换必须以可信任的方式进行，这一点很关键，也是需要数字证书的根本原因。数字证书是用被信任的第三方的私钥进行数字签名的报文，该第三方声称一个特定的公钥属于有一个特定名称和一组属性的人或物。如果初始的公钥交换不以可信任的方式执行，要冒充一个特定的实体是很容易的。
    数字签名不提供报文内容的机密性保护，但是，对报文发起者的证明比隐藏报文的内容常常更为必要。正如路由更新在核心网络中进行传递的情况一样，要求报文的认证和完整性而不要求机密性好像是有道理的。路由的内容可以不是机密的，但是确保路由更新的发起者是可信任的就很重要。在线商务和银行交易是显示对报文发起者进行认证的重要性的另一个例子，在进行任何之前必须证明其来源。
    RSA算法和数字签名标准（DSS）算法是一些更常用的公钥数字签名算法。DSS是由NIST提出的基于EI Gmal公钥算法。与RSA相比，DSS生成密钥的速度快，生成签名的性能一样，但是DSS验证签名要慢得多。
2.认证和授权
    认证和授权是安全通信的关键部分，必须得到重视。认证（authentication）证实了信息发送方和/或接受方的身份。如果发送方和接收方的身份没有得到证实，通常任何完整性检查或机密信息都是没有意义的。
    在大多数网路资源访问需求中，授权（authorization）通常与认证紧密结合。在你已经证实了自己的身份后，授权确定你能做什么。授权也称作访问控制（access control）、权限（capabilities）和许可（permissions）。授权不总是要求预先（priori）认证，通常任何认证过程之后都有授权。
    与认证和授权相关的问题包括：用来验证实体身份的方法的健壮性，建立信任域以定义授权边界和对命名空间唯一性的要求。
2.1认证方式
    所有认证方法都要求你指定自己是谁，并传递适当的凭证来证明自己是谁。这些凭证通常采取你知道什么、你具有什么或你是什么的形式描述。你知道什么也许是口令。你具有什么也许是智能卡。你是什么则与生物测定领域有关，在其中将使用完善的设备来扫描人的指纹或眼睛，或识别某人的声音，从而提供认证。
2.2信任模型
    信任（trust）是指鉴定地相信另一个人或物的诚实性、完整性、可靠性、公正性等。授权（authorization）是指当你的身份建立之后允许做一些什么事情。所有安全系统都必须根据企业的策略，有一个用于认证的框架--这个框架就叫做信任模型（trust model）
    在网络世界中，信任模型可能会相当复杂。假设我们拥有一个大企业，其中有许多相互有关联的部门，如研发部门、市场营销部门和人事部门等。各个部门可以自主组件他们的网络，但本质上是一个合作的整体。每个部门建立一个可信任的中介实体，它保存着该部门员工的全部认证和授权信息。
    当研发部门的一名经理想要在研发服务器之外访问一个文档时，他必须由研发部门的认证/授权服务器进行认证。现在如果这名经理还想要访问他的下属员工的工资信息，则必须有一种相应的认证机制，让他得到访问人事部门信息的授权。解决办法是，不是每个部门服务器为每个用户建立单独的账户信息（这种安排将可能会使得用户管理的工作 非常复杂），而是用继承信任（inheritde trust）创建一个用户组。例如，你可以在工资服务器上创建一个经理组，允许企业的任何经理访问工资信息。
    信任委托（delegation of trust）指授权给某人或某物代表自己执行操作。如果研发部门的经理出去休假了，并且让另外一个人负责，那么这个人就可以具有代理经理修改人员工资的权限。当经理回来之后必须收回这种授权，因为这种委托只是一种临时性的授权。
    在许多信任模型中，困难在于决定信任对象。权衡风险因素（如果不适当地设置了信任可能造成的损害的大小）并使用适当的机制来处理不恰当设置信任的问题，应当是每个企业安全策略的一个组成部分。
    注意：信任（trust）并不是隐含（implicit）的信任，认识到这一点很重要。你应该让一个信任模型以最高的可靠性工作，但你必须验证信任关系，并设置一些检查，以验证信息没有被篡改。
2.3命名空间
    信任域定义了授权边界，每个信任域都有一个唯一的标识符来表示其中的实体是非常重要的。首先，创建一个唯一的标识符看上去似乎是微不足道的事情，但是随着信任域规模和数量的增加，问题可能会变得非常复杂。
    考虑一种简单的情况：一个典型的企业网络。企业A是一个刚起步的小企业，员工用他们的名字作为登录ID企业B决定收到企业A，现在有许多员工工具有同样的登录ID。为了正确进行认证和授权，ID必须保持唯一。通常对于这种企业有一个命名规则：登录ID由用户的名的首字母和姓组成，当发生重复时，则使用名的前两个字母和姓或者名的前三个字母和姓，以此类推。
    许多大型企业为可能需要认证的所有实体（例如员工和任何网络基础设施设备）创建了标准的命名规则。对象标识符的概念已经在各个行业中使用，常见的情况是每个实体都有一个特定的名字。对象标识符还可以是员工的工作证编码、员工的社会保险号、设备的IP地址、MAC地址或电话号码。在给定信任域内，这些对象标识符必须是唯一的。
2.4密钥管理
    在安全通信中，密钥管理里是一个难题，这主要是因为社会原因而不是技术原因。人们已经开发出了用于创建和分配密钥的加密方法，并且这些方法相当健壮。但是，任何安全系统中最薄弱的环节是负责保存密钥和私钥机密性的人。把这些密钥保存在一个安全的地方，而不把它们写下来或告诉别人，这是一项社会性的艰巨任务，尤其是在人们面临贪婪和愤怒的时候。在100万美元面前，有些人很难在守口如瓶。在面对看来不太公正的老板时，有些人很难保证不泄密。另外有一些人不把安全规程当回事，有时候认为它们是多余的，在保管秘钥时粗心大意。人类自身的因素总是一个非常大的问题，因而需要进行充分的检查，以确信密钥没有泄露。
2.4.1创建和分配密钥
    对于少量的通信实体来讲，创建一个密钥并人工进行分发并不是不合理。但是在多数大规模的企业中，这种机制是不太可能的，也是过时的。因为密钥加密经常用于保密的应用程序中，每个会话都可能存在一个密钥。一个会话（session）是指在两个实体间任何一次通信数据传输。对于拥有数百台通信主机的大型网络，每台主机每个小时都具有无数次会话，密钥分配和传输是个相当大的问题。密钥分配经常通过集中式的密钥分配中心（key distribution center，KDC），或通过公钥算法以一种安全的、分布式的方式建立密钥来实现。
    集中式的密钥分配模型依赖于可信任的第三方，即密钥分配中心（KDC），它负责向通信实体发放会话密钥。
    集中式的分配模型要求所有的通信实体用一个共享的密钥来与KDC进行秘密通信。如何把这个共享密钥分配给每个通信节点这一问题依然存在，但没有那么严重。KDC是用每个共享密钥手动配置的，并且每个通信节点配置了相应的共享密钥。密钥可以在员工领取工作证或从IS部门领取设备（作为初始系统设置）时分发。
    注意：如果给一个设备提供了密钥，然后任何使用设备的人可以被授权，以访问某些特定的网络资源。在这个移动主机的年代，验证一个设备并让用户使用该设备来访问网络资源是一种相当不错的实践。
    以分布式的方式创建秘密会话密钥的一种常用方法是Diffie-Hellman算法。Diffie-Hellman算法提供了一种为双方建立一个共享密钥的方法，并且这个共享密钥只有双方知道---即使它们是在一个不安全的通道上进行通信。然后这个密钥采用它们所喜欢的密钥加密算法来加密数据。
    Diffie-Hellman交换可能受到中间人的攻击，因为交换本身没有认证。在攻击中，一个对手C截获了A的公钥并把自己的公钥发送给B。当B传输她的公钥时，C用她自己的公钥代替B的公钥发送给A。这样C和A协商了一个共享密钥，而C和B协商了另一个共享密钥。在这次交换之后，C可以解密A或B发出的任何报文，在阅读并可能修改报文之后，再用正确的密钥重新加密，然后把报文传输给正确的接收方。为了阻止这种情况发生并确保交换中认证和完整性，进行Diffie-Hellman交换的双方可以通过使用数字签名和公钥证书来证明他们自己的真实性。
2.4.2创建和分配公钥
    对于公钥算法，创建公/私钥对是相当复杂的。密钥对遵循改变公钥算法所定义的严格规则，以确保每个公/私钥对的唯一性。唯一性是“统计上”被保证的，也就是说，独立地生成两个密钥相同的概率几乎可以忽略。与生成公/私钥对对相关的复杂性是创建一组满足算法（例如，主要是RSA和其他许多算法）需要的参数集。
    注意：对于（密钥所标示的人或物），最理想的情况是由他们自己来生成密钥对。私钥应当始终由端用户拥有。在这种情况不太现实的企业的环境中，或在需要密钥约定由第三方托管的企业环境中，将应用不通的规则。但是，所有的技术解决方案应当尝试自己生成密钥作为设计体系结构的首要目标，这样只有创建密钥对的实体知道私钥。
    现在的问题是如何才能用一种安全的方式分配公钥以及怎样才能信任给你密钥的实体。对于数量较少的通信团体，可以考虑打电话或直接见面来给出自己的公钥。
    永远不要相信一个公钥属于某一个人。现在，许多组织有所谓的密钥签名会议（key-signed parties），人们聚到同一个房间里，并交换各自的公钥。房间里的某些人也许确切知道某个人是谁，但是有时候也有必要用驾驶执照来提供身份证明。
    当缺乏可信任的第三方时，密钥签名会议是非常重要的。一个可扩展性好的方式是使用数字证书来分配公钥。数字证书要求使用可信任的第三方---认证授权中心。
    注意：没有必要使用一种公钥加密系统的复杂密钥分配方法来确保数据机密性。用公钥进行加密的数据的安全不取决于对发布公钥的那个人的认证。公钥加密系统只是用来加密报文，用众所周知的公钥和用从可信任的认证授权中心得到的公钥所加密的报文的健壮性相同的。在公钥系统中，只有当你需要对声称与该公钥相关的人的真实认证时，密钥分配才是个问题。
    A. 数字证书
    数字证书（digital certificate）是一条数字签名的报文，它通常用于证明一个实体的公钥的有效性。主要要求一种公共的格式，并且现在主要是建立在ITU-TX.509标准的基础之上。
    一个X.509证书的通用格式有以下元素构成L
    ○ 版本号
    ○ 证书的序列号
    ○ 发布者算法信息
    ○ 证书的发布者
    ○ 有效起止日期
    ○ 证书主题的公钥算法信息
    ○ 发证机构的数字签名
    数字证书是证明实体的公钥有效性的方式，并且将来有可能成为在企业网络中提供唯一登录能力的机制。但是，就其部署而言，这种技术仍处于起步阶段。证书的大部分格式都已经被定义，但仍然需要确保证书的有效性、可管理的，并且具有一致的语义解释。
    B. 认证授权中心
    认证授权中心（Certificate Authority，CA）是保证证书有效性的可信任第三方。CA负责注册证书、分配证书，并且在证书所包含的信息无效时最终删除（撤销）证书。
    B如何如何使用CA，以可以信任的方式或得A的公钥：
    第1步：B向CA请求A的数字证书。
    第2步：CA发送用CA的私钥签名的A的证书。
    第3步：B接收到证书并验证CA的签名。
    第4步：因为A的证书包含她的公钥，所以现在B有了一个经过“公正”的A的公钥。
    该方案依赖于CA的公钥，该公钥以一种安全的方式分配给用户。最可能的是，这将使用一种带外（out-of-band）机制来实现。在因特网上应该由谁来维护CA仍然是一个备受争议的话题。许多组织（包括金融机构、政府机关和应用厂商）已经在提供证书服务方面表示了兴趣。在所有情况下，都是基于信任的觉得。有些企业或许想控制自己的证书基础设施，而其他一些企业则可能选择可信任第三方来管理他们的证书。
2.5密钥托管
    密钥托管（key escrow）是这样一个概念：由第三方保管机密密钥或私钥，知道满足特定的条件。就其本身而言，这不是一个坏主意，因为有时候很容易忘记一个私钥，或者当存储私钥的系统出现故障时，可能会丢失私钥。争议集中在哪些密钥应当被托管，以及谁可以成为可信任的第三方（可以访问机密密钥但是仍然确保密钥所有者的隐私）。
    到目前为止，最具争议的密钥托管问题在于加密系统是否应当留有一个后门，以满足电话窃听的目的。