Question

我正在创建一个基于codeigniter的应用程序，并且将作为API Centric应用程序工作，我想实现安全性，以便从他们自己的门户访问API的用户应该从我的门户获取公钥和私钥，然后每个请求他们发送到我的服务器获取数据应该通过公钥加密，服务器应该使用私钥解密数据获取存储在数据库中的私钥

现在的问题是我如何实现它，以便用户不应该使用公钥进行硬加密，我也应该能够使用codeigniter中的私钥来解密信息。如果加密是通过javascript进行的，它仍然应该通过codeigniter解密。我需要一些安全的方法来做到这一点，这样我就可以避免中间人和其他威胁中的人

由于

Answer 1

答案很简单，使用TLS。

如果您已将服务器界面实现为Web API，那么这就像配置Web服务器前端以接受HTTPS上的连接一样简单。您的Web服务器（以及客户端的浏览器/ HTTPS客户端库）将为您处理大多数复杂的握手，身份验证和加密详细信息。

TLS远非一个完美的安全协议，但如果使用得当，它通常可以完成这项工作，并且它可以通过很多减少麻烦或错误的机会而不是设计自己的协议。< / p>

如果你真的想要自己推动自己的＆＃34;安全通信方案，您首先必须熟悉密码学理论和各种可用算法。特别是，为了实现有效的hybrid cryptosystem，您需要：

基于身份验证的公钥key agreement protocol（最好基于Diffie–Hellman key exchange，因此提供forward secrecy）为客户端和服务器提供临时共享密钥;
authenticated symmetric encryption算法，使用共享密钥在客户端和服务器之间提供安全通道;以及
如果数据在安全通道内作为离散消息传输，则是一种能够检测message replay attacks的通信协议（例如，通过使用顺序消息号）。

虽然所有这些都可以使用少量离散加密原语实现 - 分组密码（例如AES），公钥加密/签名算法（例如RSA），以及可能的哈希函数（例如SHA-256）以及为Diffie-Hellman进行模幂运算的一些方法 - 它通常更容易使用加密库已经为其实现高级接口的协议和方案。

不幸的是，最广泛实施的方案也往往是较旧的方案，可能比较现代的方案更慢，安全保障更弱。也就是说，如果我有选择（并且请记住，我绝不是真正的加密专家），这就是我所选择的：

如果客户端需要使用密码进行身份验证，我选择SRP作为密钥协商协议。如果双方都知道另一方知道公共signature密钥，那么问题就更简单一些，只需使用原始的Diffie-Hellman然后让双方签署D-H共享密钥，或者使用某些东西来处理比如STS。（请注意，即使使用SRP，您仍可能希望服务器使用比客户端密码验证程序更强大的功能向客户端验证自身。）

对于签名算法，只要密钥长度足够，RSA（proper padding），DSA或ECDSA中的任何一个都应该这样做。（足够的取决于算法。）在需要哈希算法的情况下，我现在会使用SHA-2;一旦SHA-3标准最终确定，它也应该是一个有效的选择。
对于对称加密部分，我选择SIV（RFC 5297）以获得最大程度的万无一失，如果速度很关键，我会使用GCM或者＃34; -line＆＃34;需要加密大型邮件（并且您不必自己实施）。 OCB也可以是一个选项，如果patent exemptions足以满足您的目的，EAX也非常好，如果不是绝对最快的话。另请参阅How to choose an Authenticated Encryption mode。

块密码的通用组合（例如在CTR mode中）和MAC也可以工作，只要您确保在加密后将MAC应用于消息（在解密之前验证它）。任何体面的MAC都应该这样做，但HMAC通常是一个安全可靠的选择，如果你有一个好的哈希函数并且不需要极速。（如果你这样做，像poly1305-AES这样的快速Carter-Wegman MAC可能值得考虑。）如果可以，尽量避免使用旧的CBC-MAC; CMAC要好得多。

在任何情况下，我认为目前没有任何理由为基础分组密码选择AES以外的任何内容，尽管设计协议总是很好，以便新密码将来可能很容易引入选项（以及旧的不安全选项）。

要从D-H / SRP共享密钥中派生对称加密密钥，您需要generally key derivation function; HKDF（RFC 5869）是这项工作的不错选择，特别是如果您已经使用哈希函数。（不应该使用它 - alone, at least - 用于散列密码;为此，你需要一个像PBKDF2或scrypt这样的密钥拉伸KDF。）

此外，如上所述，我将设计我的通信协议，以便所有消息都带有顺序消息号和明确的发送者/接收者指定，因此具有重复消息号或无效指定的消息将被丢弃作为伪造。方便的是，这些消息号+指示符也可以用作对称加密协议的nonces（可能在散列之后，如果它们会太长）。

这些消息编号和指示符不一定必须加密（尽管他们做需要被认证为＆＃34;相关数据＆＃34;）;不加密它们的优势在于，即使在尝试解密之前，您也可以立即拒绝任何带有虚假号码或指示符的消息。

最后，请务必记住，我在上面建议的内容或您选择应用我的建议的方式可能存在可利用的差距。确保尽可能多的有能力的安全专家审查您的协议和实施，然后再将其用于任何实际重要的事项。

对于您提到的各种语言的特定加密库或API，我并不是特别熟悉，因此无法提供详细的建议。只需查看标准加密库的文档，看看它们提供了什么。

Answer 2

为最终客户端和服务器创建签名。

$key='any key';

$timestamp='current time stamp'

$url='url to access the file'

$signature = $sha1($key,$timestamp,$url);

在两端使用此功能，匹配签名值，然后让访问数据。

在codeigniter中加密和解密

2 个答案: