HMAC-MD5

MD5---- Hash加密算法（本质上说不是加密算法，因为无法解密，准确来说是一种签名算法）

---

MD5算法在实际应用中常用于鉴别信息的加密存储（鉴别信息在传输前通过MD5转为密文，与数据库中鉴别信息进行比对，在等保测评中符合鉴别信息在传输过程中的保密性和完整性）

---

其实在Java库当中，java.security.MessageDigest 已经实现了Md5算法(ps：该类实现了Md5和SHA算法，我们可以根据需要调用相应实例)我们可以直接调用，信息摘要是安全的单向哈希函数，它接收任意大小的数据，并输出固定长度的哈希值。

import java.io.UnsupportedEncodingException;
import java.security.MessageDigest;
import java.security.NoSuchAlgorithmException;

public static String getDigest(String msg) throws NoSuchAlgorithmException, UnsupportedEncodingException
{
		final MessageDigest md5 = MessageDigest.getInstance("MD5");
		final byte[] byteArray = msg.getBytes("UTF-8");
		final byte[] md5Bytes = md5.digest(byteArray);

                //将生成的md5Bytes转成16进制形式
		final StringBuffer hexValue = new StringBuffer();
		for (int i = 0; i < md5Bytes.length; i++)
		{
			int val = ((int) md5Bytes[i]) & 0xff;
			if (val < 16)
				hexValue.append("0");
			hexValue.append(Integer.toHexString(val));
		}
		return hexValue.toString();

}

MD5Hash算法的特点：
1：输入任意长度的信息，经过摘要处理，输出为128位的信息.。（数字指纹）
2：不同输入产生不同的结果，（唯一性）
3：根据128位的输出结果不可能反推出输入的信息(不可逆)

既然不可能反推出输入的信息，可以说Md5只能用于信息验证，而不能用来加密解密进行消息传递。这是与RC4的根本区别。

MD5Hash算法作用：
1：防止数据被篡改
2：防止直接看到明文 ps:在密码存储中，即使采用md5存储密码也是有可能出现安全漏洞的，比如撞库的暴力破解
3：数字签名
先介绍到这里，等下补上H-MAC的

HMAC算法的实现过程需要一个加密用的散列函数（表示为H）和一个密钥。
一般我们采用的散列函数为Md5或者SHA-1，这两个散列函数的分割数据块长度都是64字节，即512位，HMAC-MD5算法就是采用密钥加密+Md5信息摘要的方式形成新的密文。
由于数据块长度为64，为了保证密钥+data进行digest的时候的数据完整性(为什么需要保证？)最终加进数据的密钥保证为64个字节长。
密钥的长度可以是小于等于数据块长度的任何正整数值。应用程序中使用的密钥长度若是比B大，则首先使用散列函数H作用于它，然后用H输出的L长度字符串作为MAC中实际使用的密钥。一般情况下，推荐的最小密钥K长度是L长(与H的输出数据长度相等，比如MD5的L就是16字节，SHA-1是20字节)

过程如下：
(1) 在密钥key后面添加0来创建一个长为B(64字节)的字符串（str）；
(2) 将上一步生成的字符串(str) 与ipad（0x36）做异或运算，形成结果字符串（istr）
(3) 将数据流data附加到第二步的结果字符串(istr)的末尾
(4) 做md5运算于第三步生成的数据流(istr)
(5) 将第一步生成的字符串(str) 与opad（0x5c）做异或运算，形成结果字符串（ostr）
(6) 再将第四步的结果(istr) 附加到第五步的结果字符串（ostr）的末尾
(7) 做md5运算于第6步生成的数据流（ostr），最终输出结果(out)

注意：如果第一步中，key的长度klen大于64字节，则先进行md5运算，使其长度klen = 16字节

有人说HMAC-MD5的产生是因为碰撞率 比MD5更低？


HMAC-MD5的应用？先看下面这篇文章
通过实例演示如何建立基于SSL的安全通道连接

在当前世界中，网络已成为不可或缺的元素。它将原来遥不可及的事物，方便快捷的联系到一起。为了充分利用网络所带来的便捷，越来越多的企业选择将信息发布在网络上。电子商务、物联网、云计算与服务，也都在计划与实施中。与此同时，网络的普及，也给信息安全带来了挑战。如何保证信息在不可靠网络中的安全传输，成为企业 IT 实施优先考虑的问题。

SSL 是指安全套接字（Secure Socket Layer），是应用最为广泛的安全协议。它在 TCP/IP 协议之上提供了一条安全通道，可以保证在不安全网络环境下的数据安全。它支持各种加密算法、数字签名、数字证书，可以防御常见的网络攻击。WebSphere MQ 对 SSL 具有很好的支持，从而保证消息在网络中安全的传送。本文在介绍 SSL 的基础上，以实例方式详细描述了如何在 MQ 中实现基于 SSL 的安全传输。文章中的实例，主要基于 MQ 7.0.1.9，同时也会介绍新版本 MQ 7.1 及 MQ 7.5 的变化。

网络攻击类型及应对策略

网络将数以千万计的机器连接在一起，环境复杂多变，所以网络攻击也是花样百出。这里，根据攻击对消息产生的影响，主要可以划分为三类：窃听、篡改、仿冒。这三种攻击方式，分别会破坏消息的私密性、完整性和通信双方的互信。针对这些攻击的特点，SSL 提供了可靠的防御策略。

1)窃听与加密

窃听，即偷听别人的谈话，在网络中意味着拦截消息并偷看其中的内容。那么，为了避免消息被别人窃听，就需要对消息进行加密。这样，即使消息被攻击者截获，他们也无法轻松获知其中的内容。

加密即按照一定的规则（加密算法）将原消息（明文）转化为对窃听者不可读的密文。通信双方共享加密的规则，所以消息接收者可以将密文再转回可读的明文。密钥是一个随机字符串，是加密及解密不可或缺的元素。发送者使用密钥对明文加密，接收者使用密钥对密文解密。

通信双方可以共享一个相同的密钥，用于加密和解密。这称为对称加密或者秘密密钥加密。这种方法的优势是速度快，劣势是难以安全的传递密钥，特别是有很多通信对象时。要安全的将密钥交到通信方，你需要和每一个人见面。为了解决这个问题，就出现了不对称加密或者公共密钥加密。使用这种方法，每一个通信对象都有一个密钥对：公钥和私钥。发送者使用对方的公钥加密，接收者使用自己的私钥解密。因为公钥是公开的，这就解决了密钥传递的问题。但是，也造成了一些性能的损失。在实际的应用中，为了避免密钥传递问题同时保证性能，通常使用不对称加密来交换密钥，然后使用对称加密传输数据。

加密是一个非常重要，也非常活跃的研究领域，有非常多的加密算法。例如，数据加密标准（DES），三重 DES，RC2 和 RC4 等。

2)篡改与消息摘要

篡改是指攻击者拦截并修改消息的内容。加密不能避免消息被修改，接收者也无法判断消息是否被修改过。这里，就需要用到消息摘要（Message Digest）技术。消息摘要是一个表示消息特征的定长字符串。它有两个重要的特征：不可逆性和抗冲突性。不可逆性是指从消息可以计算出消息概要，但是从消息摘要基本不可能得到消息；抗冲突性是指要想产生具有相同摘要值的两条消息是相当困难的。这两个特性，使消息摘要可以用来验证消息的完整性。发送者使用摘要算法计算出消息摘要，并随同消息发送给对方；接收者收到消息以后，同样会根据消息计算出消息摘要 , 并和收到的摘要对比。如果两者相同，则表示消息没有被篡改。

在实际应用中，消息摘要很少被单独使用，通常用于数字签名和消息认证码（MAC）。消息认证码是基于消息和密钥生成的消息摘要。它在验证完整性同时，可以在一定程度上完成用户验证功能。数字签名是经过加密的消息摘要。

(PS:似乎就是消息被篡改了我必须知道，从而发现并处理这个篡改事件)

3)仿冒与数字证书

仿冒即假冒别人进行通信。消息认证码可以用来验证消息的发送者。数字签名则更进一步，具有不可抵赖性。因为数字签名是使用发送者私钥加密的消息摘要，只有发送者才能产生。这一切似乎都很完美，使用加密防止窃听，使用摘要防止篡改，使用数字签名防止仿冒，似乎不要什么数字证书。

事实当然不是这样，下面的攻击方式将瓦解以上所有的防线。这就是中间人攻击（man-in-the-middle attack）。在通信双方交换公钥的过程中，攻击者拦截双方的公钥，并将自己的密钥发送给通信双方。这样，通信双方就会使用攻击者的密钥加密。在这样情况下，所有的加密、签名都失效了。中间人攻击细节如下图所示：

图 1.中间人攻击

就会使用攻击者的密钥加密。在这样情况下，所有的加密、签名都失效了。中间人攻击细节如下图所示：

图 1.中间人攻击

从上图可以看出，第 1, 2, 3, 4 步是公钥交换过程。在此过程中，攻击者获得了发送方和接收方的公钥，而将自己的公钥发送给通信双方。第 5, 6, 7, 8 步是发送消息的过程。在此过程中，发送方和接收方都是用攻击者公钥加密，而攻击者截获数据后重新使用通信双方公钥加密，这就使双方难以察觉攻击者的存在。

要防范中间人攻击，就需要使用数字证书，这里，数字证书主要指由专门的证书颁发机构（CA）授权的证书，称为 CA 证书。CA 证书将证书属主信息和公钥绑定到一起。证书颁发机构负责验证证书申请者的身份信息。通过可信的第三方（CA），通信方可以向任何人证明其拥有的公钥，其他人也可以通过 CA 验证其证书真伪，这就阻止了中间人攻击。CA 证书一般包含所有者的公钥 , 所有者的专有名称 , 签发证书的 CA 的专有名称 , 证书开始生效的日期 , 证书过期日期等信息。

与 CA 证书相对应的，还有自签署证书。

自签署证书一般用在测试环境中。在后面的章节中，会使用自签署证书实现基于 SSL 的安全连接。

SSL 握手

SSL 连接实现主要分为两部分：SSL 握手和数据传输。前者使用 SSL 握手协议建立连接，后者使用记录协议传输数据。这里，主要介绍 SSL 握手流程。握手是 SSL 客户端和 SSL 服务器端完成认证，并确定用于数据传输的加密密钥的过程。这里，SSL 客户端是指主动发起连接的一端，不要和 MQ 客户端混淆。SSL 握手具体流程如下：

1. SSL 客户端发送“Hello”消息给 SSL 服务器端，并列出客户端所支持的 SSL 版本、加密算法和摘要算法。在实际应用中，一般将加密算法和摘要算法结合到一起，组成一个加密套件。同时，客户端还会发送一个随机数，用于以后产生加密密钥。
2. SSL 服务器端对客户端的连接请求作出回应。从客户端提供的加密套件列表中，选择要使用的加密套件，并产生另外一个随机数。同时，服务器端会发送自己的数字证书给客户端，里面包含服务器端的认证信息及公共密钥。如果服务器端需要验证客户端，它还会在消息中包含要求客户端提供数字证书的请求。
3. 客户端收到服务器端的回应。它首先使用 CA 证书验证服务器端证书的有效性。在此过程中，客户端会检查证书的签名、证书认证路径、有效日期、证书状态等。验证通过后，抽取出其中的公钥。客户端产生另外一个随机数，并使用服务器端的公钥加密后发送给服务器端。
4. 如果服务器端要求客户端提供证书，客户端会将随机数用私钥加密，连同证书发送给服务器端。服务器端对客户端的证书进行验证，并使用客户端的公钥解密收到的随机数。
5. 服务器端和客户端基于前面提供的随机数，计算出用于数据加密的共享密钥。
6. 客户端将所有握手消息的 MAC 值发送给服务器端，服务器端也将所有握手消息的 MAC 值发送给客户端。这么做是为了防止攻击者在握手过程中篡改了消息内容。
7. 客户端和服务器端使用握手过程中产生的加密密钥交换握手结束消息。握手结束，SSL 连接建立。

在 SSL 连接建立后，将开始遵循记录协议对数据进行传输。

WebSphere MQ SSL 配置与管理

WebSphere MQ 支持安全套接字协议（SSL）和传输层安全协议（TLS，是 SSL 的后续版本）。在本章中，主要介绍 GSKit，以及与 SSL/TLS 相关的队列管理器属性及通道属性。用户可以使用 MQ 资源管理器设置这些属性，也可以使用 MQSC 命令设置。

MQ 与 GSKit

MQ 对 SSL 的支持，是通过 GSKit（Global Security Kit）实现的。GSkit 提供实现 SSL 所必须的函数库及工具，被应用于很多 IBM 产品。

在 MQ 7.0 及以前的版本中，GSKit 是单独安装的，版本是 GSKit V7.0。从 MQ 7.0.1 开始，引入 GSKit V8.0 作为可选版本。在 MQ 后续版本 MQ 7.1 和 MQ 7.5 中 GSKit V8.0 完全取代 GSKit 7.0，成为默认版本并集成到 MQ 安装包中。

与 GSKit V7.0 相比，GSKit V8.0 支持新的更安全的散列算法 SHA-2，支持所有 Java 环境中的密钥重置，支持更严格的 FIPS 认证以及多语言的错误输出。具体的细节，请参考 MQ 信息中心文档。

GSKit V7.0 和 GSKit V8.0 可以共存于同一系统中，不同的队列管理器可以选择使用不用的 GSKit 版本。

此外，GSKit V8.0 还集成了 GSKCapiCmd 命令，用于管理密钥、证书请求及证书。同时，用户也可 iKeyman （IBM Key Management）工具实现同样的功能。一般来说，iKeyman 可以随 MQ 一起安装，并且具有 GUI 界面，使用比较方便。

---

（注：本文部分内容来源于网络）