文件存储到 服务器 加解密,文件加解密 - 密钥保存

当我们想做一个加解密系统的时候，有个问题还是绕不过的，就是如何保存加解密的密钥。

通常如果想做文件的加解密，都是用的对称算法，一般就是AES或者DES。

那这里有个问题密钥怎么管理呢？

基本上可以分两种：

1. 直接把文件加密，然后密钥信息保存在文件外。比如我们把C:\test.txt加密了，就生成一个密文。然后把密钥保存在某个地方，比如数据库。我们可以在数据库里面增加一个记录，如：

path                                     key

c:\test.txt                              123456789

当要解密的时候，就根据路径到数据库里面去查找对应的key，再进行解密。这么做有一个比较麻烦的问题，就是如果用户把这个文件copy到另外一个目录，那么就需要更新数据库。这就相当于我们需要监控这个文件c:\test.txt的动态。每一次移动copy什么的，都需要更新数据库，很麻烦。

2. 定义一个自己的文件格式。

一般来说，会把密文放在自定义文件的后面，前面加上一个文件头metadata。(也有把密文放在前面，metadata放在后面的)

这种方式就会比第一种好一些，因为我们可以在metadata里面放入一些我们自己的数据。比如：密钥信息，tag啥的。

自定义的文件格式就方便多了，如果用户移动了这个文件，也没关系，因为文件头metadata是跟着走的。

但是这里有个问题，就是metadata里面的某些信息是需要加密存放的。我们总不可能把文件内容加密密钥明文放在metadata里面吧？如果这样的话，只要打开这个文件，就可以在头上看到加密密钥了，一下就可以解开密文了。

所以加密密钥本身也需要加密然后再放在metadata里面。

那么加密 “密钥”的密钥又放在哪里呢？

这个地方就需要有一个管理 (加密“密钥”的密钥) 模块。通常会把这个叫做KMC (Key Management Center)

加密 “密钥” 是使用非对称还是对称算法呢？

我觉得都可以，具体看需求。但是无论采用非对称还是对称算法，都需要一个KMC 服务器。

如果是使用非对称算法的话，KMC服务器需要产生一对key：公钥和私钥。把公钥发给客户端，客户端就可以用公钥把文件内容的密钥(如123456789...，AED256的话，就应该有32个字节)进行加密，然后把密钥密文放在metadata里面。当需要解密的时候，有两种做法：a)把文件头(metadata)发给服务器，服务器用私钥把“文件内容密钥”解开，并且发回给客户端，这样客户端就可以用解开后的密钥解密文件内容了。b) 服务器把“文件内容密钥”密文对应的私钥发给客户端，客户端自己去解开得到文件内容密钥，然后再去解开文件内容。

如果使用对称算法加密“文件内容密钥”的话，也是类似的。

一个KMC服务器肯定会有多个非对称密钥或者对称密钥的，所以，我们一般还需要一个id来标志密钥。通常的做法就是KMC服务器会把公钥(非对称)或者密钥(对称)和对应的ID 发给客户端。客户端把文件内容密钥加密后， KMC发过来的密钥就需要毁灭(以免在内存里面存在时间过长，而被人dump内存看到)，然后把文件内容密钥的密文和对应id放在metadata里面。

举个例子，比如文件内容密钥是01234567890123456789012345678901

然后

1. 向KMC服务器申请一个key(非对称，对称都行)

2. 用key把01234567890123456789012345678901进行加密可得xxxxxxxxxxxxx

3. 把key毁灭

4. 把密文xxxxxxxxxxx和对应的id比如10放到metadata。如下图。

这样，当我们要解密的时候，可以把id：10发给KMC服务器，KMC服务器就会发回对应的key，然后就可以把xxxxxxxxx解开变成01234567890123456789012345678901了，这样就可以拿01234567890123456789012345678901来解开文件内容了。(当然也可以把整个文件头发给KMC，让KMC直接解开xxxxxx,这个具体看设计)。

如果是自定义文件格式，那么一般都是这么做的。

有几个地方需要注意一下：

1. 客户端和KMC服务器的通信最好要采用安全通信，比如ssl，不然那些密钥信息比较容易被人截获到。

2. 对于解密者的身份最好也要认证，不然谁都可以写一个exe来冒充你来和KMC进行通信了，一般使用数字证书就可以了。比如可以对exe进行签名等。