我试图设计一种安全方案，用于加密Silverlight客户端和我创建的PHP Web服务之间的应用程序级数据。由于我正在处理一个公共网站，因此我从服务中提取的信息是公共的，但我向Web服务提交的信息不是公共的。还有一个网站后端用于管理，因此所有从Web服务推送到Silverlight管理后端的应用程序数据也必须加密。
Silverlight不支持非对称加密，这对于公共网站有效。对称加密仅适用于后端，因为用户不会登录公共网站，因此不能派生基于密码的密钥。尽管对称加密很好，但我无法安全地保存私有密钥在Silverlight客户端中。因为它要么必须硬编码，要么从某种配置文件中读取。这都不被认为是安全的。那么...计划B。
我的最终替代方案将是实现Diffie-Hellman算法，该算法通过密钥协定支持对称加密。但是Diffie-Hellman容易受到中间人攻击。换句话说，没有保证任何一方确定对方的身份，这可能导致通信被拦截并更改而接收方不知道。因此，建议使用私有共享密钥加密密钥协商握手，以确认任一方的身份。
这使我回到了最初的问题，这让我需要使用Diffie-Hellman，如何在Silverlight客户端中使用私钥而不在代码或XML文件中硬编码它。
对于这个问题我没有答案...有吗？
编辑：
请记住，这是关于我自己推出的自定义PHP Web服务。
我找到了一个RSA实现，我可以在Silverlight中使用。似乎相当安全使用它来加密Silverlight客户端和PHP Web服务之间DiffieHellman密钥协议的握手，并随后使用它来加密已经商定的对称密钥（该密钥本身是通过哈希结果生成的密钥交换）。
此后，我几乎可以保证所有发送给Web服务的通信都没有被拦截、修改并重新传输（MITM）。但我认为仍然可能，从技术上讲，攻击者可以冒充Silverlight客户端并向Web服务发送消息（假设他们发现了URL）。
未经授权访问的安全性得到了保障，因为攻击者不知道我的自定义Web服务的“secret api”，因此无法与其通信。
唯一破解这个问题的方法是通过用攻击者可能怀疑有效的任何字符串来暴力破解Web服务以尝试从Web服务获得响应。我不认为你可以暴力破解可变长度的字符串。这听起来不切实际。
有人看到这种方法有问题吗？
Silverlight不支持非对称加密，这对于公共网站有效。对称加密仅适用于后端，因为用户不会登录公共网站，因此不能派生基于密码的密钥。尽管对称加密很好，但我无法安全地保存私有密钥在Silverlight客户端中。因为它要么必须硬编码，要么从某种配置文件中读取。这都不被认为是安全的。那么...计划B。
我的最终替代方案将是实现Diffie-Hellman算法，该算法通过密钥协定支持对称加密。但是Diffie-Hellman容易受到中间人攻击。换句话说，没有保证任何一方确定对方的身份，这可能导致通信被拦截并更改而接收方不知道。因此，建议使用私有共享密钥加密密钥协商握手，以确认任一方的身份。
这使我回到了最初的问题，这让我需要使用Diffie-Hellman，如何在Silverlight客户端中使用私钥而不在代码或XML文件中硬编码它。
对于这个问题我没有答案...有吗？
编辑：
请记住，这是关于我自己推出的自定义PHP Web服务。
我找到了一个RSA实现，我可以在Silverlight中使用。似乎相当安全使用它来加密Silverlight客户端和PHP Web服务之间DiffieHellman密钥协议的握手，并随后使用它来加密已经商定的对称密钥（该密钥本身是通过哈希结果生成的密钥交换）。
此后，我几乎可以保证所有发送给Web服务的通信都没有被拦截、修改并重新传输（MITM）。但我认为仍然可能，从技术上讲，攻击者可以冒充Silverlight客户端并向Web服务发送消息（假设他们发现了URL）。
未经授权访问的安全性得到了保障，因为攻击者不知道我的自定义Web服务的“secret api”，因此无法与其通信。
唯一破解这个问题的方法是通过用攻击者可能怀疑有效的任何字符串来暴力破解Web服务以尝试从Web服务获得响应。我不认为你可以暴力破解可变长度的字符串。这听起来不切实际。
有人看到这种方法有问题吗？