详解加密算法与密钥管理

密码系统的两个基本要素是加密算法和密钥管理。加密算法是一些公式和法则，它规定了明文和密文之间的变换方法。由于密码系统的反复使用，仅靠加密算法已难以保证信息的安全了。事实上，加密信息的安全可靠依赖于密钥系统，密钥是控制加密算法和解密算法的关键信息，它的产生、传输、存储等工作是十分重要的。 ----在信息处理系统中，密码学的主要应用有两类：数据的通信保护和数据的存储保护。在这些应用领域，密码方法的使用与过去在军事、外交上的传统使用方法有很大的区别。在传统应用中，双方所需的密钥通过另外的安全途径传送；而在信息处理系统中，密钥的某些信息必须放在机器中。如此一来，总有一些特权用户有机会存取密钥，这对加密系统的安全是十分不利的。解决这一问题的方法之一是研制多级密钥管理体制。例如，在二级密钥管理体制中，一级密钥（也称主密钥）存储在安全区域，用它对二级密钥信息加密生成二级密钥（也称为工作密钥），再用工作密钥对数据加密。当然，这些动作都应该是连贯的密箱操作。然而纯软件的加密系统难以做到密箱操作。 ----实际上，无论多么高明的反跟踪技术也难以让人放心，因为软件跟踪高手会将整个程序分解、剖析。但如果把主密钥、加密算法等关键数据、程序固化在加密卡中，就能解决密箱操作的难题。主程序将待加密的一组明文数据、一组二级密钥信息传给加密卡，加密卡则完成以下的工作：用主密钥和加密算法将取得的一组二级密钥信息加密成工作密钥，再用该工作密钥和加密算法将明文数据加密并将所得密文经接口返回给主程序。 数据库密码 ----应用于数据库加密的加密算法称为数据库密码。目前常用的加密算法可分为三类： 1. 序列密码体制 ----这种密码直接对当前的字符进行变换，也就是说，以一个字符为单位进行加密变换。在这种加密体制中，每一字符数据的加密与报文的其他部分无关。例如，直接对明文加上一串同等长度的乱码（也可看成是密钥），只要所用的乱码是随机数且不重复使用，就实现了“一次一密”的加密。从理论上讲，真正实现了“一次一密”的密码是可靠的密码，原则上是不可破译的。这类密码的明文和密文长度一般不变，传递迅速、快捷；其缺点是密码破译人员比较容易得到明密对照双码，便于其进行密码分析，同时乱码的产生和管理比较困难，难以真正做到“一次一密”。该类密码适用于通信领域。 2. 分组密码体制 ----应用这类密码时，明文按固定长度分组，对各组数据用不同的密钥加密（或脱密）。这类密码按分组进行加密变换，一个字符数据不仅与密钥有关，而且还与其他字符数据有关，密码分析的穷尽量很大。例如传统的64位分组法，它的穷尽量为264－1，这是一个20位的十进制数，即使用每秒运算万亿次以上的巨型计算机进行攻击，平均穷尽时间也需要数年。当然这仅仅是理论数据，在攻击密码时还有其他约束条件，如文字、数据、环境、规律等信息，所以实际所需的攻击时间要短得多。 ----在使用分组密码时，对明文尾部不满一个整组的碎片通常采用填充随机数的办法将其扩充为一个整组，然后进行正常加密。由于尾组的扩充，使得密文的长度大于明文的长度。分组密码可用于计算机存储加密，但因为数据库加密后的数据长度不能改变，所以必须改进分组加密算法的使用方法。 3. 公开密钥体制 ----这种体制的一个例子是RSA密码。这类密码的共同缺点是加/脱密速度较慢，据报道，这类密码的运算速率仅达到其他密码的千分之一到百分之一。公开密钥体制的密码目前常用于用户认证、数字签名以及密钥传输等，不能适应数据库加密的速度要求。 ----序列密码和分组密码也称为对称性密码，这类密码加密时用某个密钥加密，脱密时还用这个密钥脱密。公开密钥密码也称非对称密码，这类体制的密码具有两个密钥：公钥和私钥，加密时用公钥加密，脱密时必须用私钥脱密。 ----数据库加密系统对数据库密码的要求如下: 数据库加密以后，数据量不应明显增加； 某一数据加密后，其数据长度不变； 加/脱密速度要足够快，数据操作响应时间应该让用户能够接受。 ----改变对分组密码算法传统的应用处理方法，使其加密后密文长度不变，就能满足以上几点要求。这里以数据加密标准DES为例进行说明。 ----DES是一种对二进制数据进行加密的算法，数据分组长度、密钥长度和输出密文长度均为64位（现在有人主张使用128位），明文经过16轮的叠代、乘积变换、压缩变换等编码过程输出密文。关于DES算法以及它对明文数据进行的复杂操作已经在很多著作中有过详细的描述，这里不再赘述。一个需要注意的问题是对尾部碎片的处理方法。传统的做法是填充数据而使其成为一个整组，这种处理方法会使数据扩张，不适用于数据库加密。为此我们采用了“密码挪用法”来解决这个问题，如下图所示： ----在该例中，待加密数据的长度为13。第一整组（1～8 码）加密后截取第6～8码的密文与尾部（9～13码）组成一个整组进行加密，加密所得密码接在前一组的第5个密码之后。其中，第6～8码实际上进行了二次加密，在脱密时也应该进行二次脱密。这种方案一方面保证了64位分组加密，同时又保证了数据库加密以后，数据长度不会变化。 ----另外，关系数据库中有些数据比较短，例如人事档案表中 “性别”字段，一般只定义一个汉字（16bit）。这类数据长度不到一个分组，如果不进行数据扩张，其密码强度会减弱，需要进行特殊处理。因此，当用户要求对这类数据加密时，系统将自动检查并将其定义为二进制64分位定长数据类型，加密时，实际数据不足一组的部分用随机数填满。 ----加密数据的数据类型需要处理，否则数据库管理系统将会因加密后的数据不符合定义的数据类型而拒绝加载。解决方法之一是另外建立密文表用于存放密文。凡是需要加密的数据都定义为计算机二进制数据类型。加密以后插入数据库的数据全部为二进制数据类型的数据，当用户检索时，加密系统自动脱密并转换成用户所需要的数据类型。 ----加密系统为数据库用户提供了定义加密要求的手段。通过系统提供的用户界面，用户可以选择需要加密的数据库表，并确定该表需要加密的列数据。 ----当应用系统输入一条数据库表记录时，系统查得该表的加密要求，如果需要加密，则对需要加密的列数据进行加密，然后将得到的密文插入到数据库表中。如果该表不需要加密，则将明文直接插入到数据库表中。 ----当应用系统查得一条数据库表记录时，如果是明文（该表没有加密要求），则直接将明文记录交付给用户；如果有加密要求，则将每个需要脱密的列数据脱密，并将所得到的明文交付给用户。 密钥管理方法 ----数据库加密需要实行二级密钥管理。一级密钥为主密钥，二级密钥为工作密钥。主密钥的作用是对二级密钥信息加密生成工作密钥。工作密钥用于对数据库数据的加/脱密。工作密钥信息的长度为64位，前56位是记录名，需要带校验地存储在数据库表中。后8位是数据库表的列（字段）信息（该字段在表中的某些特征）,它们是临时生成的。为了存储记录名数据，每个数据库表增加了一个记录名字段，在用户录入数据时，系统自动生成记录名数据，使每条记录都有一个记录名并做到各记录名数据互不重复。 ----设一个表有m列、n条记录，则对于每一个加密单位都有一个对应的二级密钥信息XiYj，组织方法如下： ----其中，Xi占56位（bit）, X序列的周期为256－1≈7 ×1016。 ----Yj占8位（bit）,允许列编号0～255，即一个数据库表最多允许256列数据。 ----XiYj的总长度为56＋8=64位（bit）。在数据需要加/ 脱密时，将相应的64位二级密钥信息用主密钥进行加密即得到工作密钥，用工作密钥完成对数据的加/脱密。 举例来说，如果一年需要1×109条记录，在足够长的时间内可提供不重复的X序列： ----（7×1016）÷（1×109）=7×107（年）。这在足够长的时间内保证了Xi信息的两两互异。目前Sybase DBMS规定，一个数据库表的列数不超过256列，这就保证了Yj信息的两两互异。由此保证了XiYj信息的两两互异，也就证明了工作密钥的唯一性。 ----事实上，数据库加密系统中还需要其他一些密钥信息。例如对于多服务器、多数据库、多用户、多用户组等情况，还需要根据应用需求增添一些信息，其方法是将以上各类实体分别进行编码、存储并依据不同情况使用。 密钥的安全保护 ----理论上讲，实现了“一次一密”密钥管理的密码是不可破译的，因此如何确保密钥管理系统的安全成为关键问题。本系统中，主密钥保护了工作密钥，工作密钥保护敏感信息，因而整个系统的安全依赖于主密钥的安全。 ----主密钥的安全需要解决以下几个问题： ----1． 主密钥的生成 ----本系统采用投币法产生64位二进制数据。 ----2． 主密钥的存储 ----主密钥经加密并存放于安全区域内，使用时由系统自动获取并脱密。本系统也可将主密钥注入加密卡中以利安全。 ----3． 主密钥的更换 ----在数据库加密课题中，主密钥的更换是一个比较棘手的问题。主密钥更换以后，会造成工作密钥的全部更换。数据库中存储着海量数据，已经加密的数据需要用原来的密钥系统脱密，而且脱密时间将会很长。为安全起见，密钥更换前，需对数据库系统进行全库备份，然后利用系统所提供的工具完成对数据库中密数据向明数据的转换。更换主密钥后，再根据数据库加密要求进行明数据向密数据的转换。 ----在大型数据库中，这种明密数据的转换工作需要认真对待。首先应该制定计划，做好充分的准备工作。对所做的工作应做好登记，使密钥更换工作有条不紊地进行。事实上，由上面密钥系统的应用分析可以知道，即使不变更主密钥，也可以在足够长的时间内保证Xi信息的两两互异，也就是说，在通常的数据库生存期内，不变更主密钥也能充分保证加密系统密钥使用的“一次一密”。只要系统管理得当，密钥系统仅需数年更换一次，或者不必更换。

转载于:https://www.cnblogs.com/mrjim/archive/2011/08/24/4475248.html