协议可以通过加密来保护吗?

发布于 2024-08-05 04:04:26 字数 173 浏览 5 评论 0原文

这是我一直想学习的。当我设计一个多个组件相互通信的系统(软件或硬件)时,如何在协议中实现一些简单的加密或其他功能来实现一些基本的安全性?

无论如何,我可以更改协议,因为我可以低级访问传输/接收的一系列字节。

编辑:我对嵌入式编程、用于协议安全的简单在线加密感兴趣。

This is something I've always wanted to learn. When I design a system (software or hardware) where multiple components communicate with each other, how can I implement some simple encryption or other features in the protocol for some basic security?

I can change the protocol anyhow, since I have low-level access down to the series of bytes that are transmitted / received.

Edit: I'm interested in embedded programming, simple over-the-wire encryption for protocol security.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(7

温柔戏命师 2024-08-12 04:04:26

你说“基本安全”,但这并没有多大意义。您的威胁模型是什么?您正在防御哪种类型的攻击?如果您要传输信用卡数据,那么您将需要使用强大的加密技术,例如 RSA。但我想不出一个需要“较少”保护的例子。如果你担心黑客会反汇编你的代码,那么游戏就已经结束了——如果它有趣或有价值,他们就会破解它。如果没有,你就浪费了时间去实施它。

You say "basic security" but that doesn't mean much. What is your threat model? What kind of attack are you defending against? If you are transmitting credit card data, then you're going to need to use robust encryption, such as RSA. But I can't think of an example that needs "less" protection. If you're worried about hackers disassembling your code, it's already game over -- if it's interesting or valuable, they'll hack it. If not, you wasted time implementing it.

渔村楼浪 2024-08-12 04:04:26

到目前为止,最简单的解决方案是仅使用 SSL 套接字而不是普通套接字,即 HTTPS/FTPS 风格。

HTTP 和 HTTPS 之间的协议没有任何区别,唯一的区别是它们在不同的端口上运行(通常为 80 与 443),一个使用普通套接字,另一个使用 SSL 加密套接字。

The simplest solution by far is to just use a SSL socket instead of a normal one, a la HTTPS/FTPS style.

There is no difference at all in the protocol between HTTP and HTTPS, the only difference is that they operate on different ports (80 vs 443 normally), and one uses a normal socket, and the other uses a SSL encrypted socket.

装迷糊 2024-08-12 04:04:26

不要从头开始设计的意义上实现基本加密。正确地正确实施加密是非常困难的。

相反,集中精力使用您平台上可用的加密...您的平台是什么?

编辑:

请参阅此 SO 帖子 以获取加密替代方案列表,其中一些应该在嵌入式环境中运行得很好(例如 CryptoPPTomCrypt)。

Don't implement basic encryption in the sense of designing it from the ground up. It is VERY hard to correctly implement encryption properly.

Instead, concentrate on using encryption available on your platform... what is your platform?

EDIT:

See this SO post for a list of encryption alternatives, some of which should work quite well in an embedded environment (e.g. CryptoPP and TomCrypt).

罪歌 2024-08-12 04:04:26

OAuth 您可能会感兴趣,以便允许各种 API 之间的访问控制。

如果您纯粹想要一个加密的数据通道,最好将其分层在您的协议之上;通过 SSL 或 SSH。

OAuth may be interesting for you, in order to permit access control between various APIs.

If you purely want an encrypted channel of data, it's better to just layer that ontop of your protocol; go over SSL or SSH.

虚拟世界 2024-08-12 04:04:26

如果您正在进行嵌入式编程,那么加密问题在哪里?

例如,只要您使用同一处理器,加密就没用。

如果您关心设备上的处理器,那么加密可能会很困难,因为 DSP 不一定有空闲空间来进行任何复杂的加密。

如果你想要快速,那么对称算法是你最好的选择,并且你可以做很多很好的算法,例如 Blowfish 或 IDEA。您可以存储唯一的对称密钥,因此如果他们可以拆开设备,只会发现一个密钥,但每个设备都应该有自己的密钥。

只需将每个密钥与序列号绑定,这样,如果您正在与服务器通信,则将序列号与数据包一起传递,网络服务器可以查找正确的对称密钥并快速解密。

如果你想做一个快速的硬件加密,在我的 MSEE 论文中,我开发了一个使用任意阶微积分的加密系列,这将很难确定密钥,因为它可以在使用微带的硬件电路中,因为没有处理,它将直接连接在天线之前,并且通过它的所有内容都将被加密。

If you are doing embedded programming then where is the encryption concern?

As long as you are staying on the same processor, for example, encryption is useless.

If you are concerned between processors on the device then encryption can be difficult, as a dsp won't necessarily have the spare space for any encryption of any complexity.

If you want fast then a symmetric algorithm is your best bet, and there are many that you can do that are good, such as Blowfish or IDEA. You can store a unique symmetric key, so if they can take the device apart, only one key will be discovered, but each device should have it's own key.

Just tie each key to the serial number, so that if you are communicating with a server then pass the serial number with the packet and the webserver can look up the correct symmetric key and decrypt it quickly.

If you wanted to do a fast hardware encryption, for my MSEE thesis I developed an encryption family that uses arbitrary order calculus, which would be difficult to determine the key as it can be in the hardware circuit using microstrip, as there is no processing, it would be tied in directly before the antenna and everything going over it would be encrypted.

风吹过旳痕迹 2024-08-12 04:04:26

设计安全系统时需要考虑很多事情。仅举几例:

  • 对称/非对称加密方案的选择
  • 加密算法(AES、Blowfish、DES)
  • 已知协议的选择(例如 SSL)
  • 密钥管理和分发
    • 单个主密钥(如果被黑客攻击,整个系统都会受到威胁)
    • 每个设备的密钥(密钥分发可能会更加困难)
    • 保护主要分销渠道
  • 潜在的黑客是否可以轻松访问示例设备?例如 X-box 等消费产品与锁定在电话交换机中的盒子。如果黑客拥有物理访问权限,则更难防范黑客攻击。
  • 人为因素——社会工程等。
  • 系统的安全取决于其最薄弱的环节。

我建议您阅读 Bruce Schneier 的初学者材料。

There are many things to be considered in designing a secure system. Just to mention a few:

  • Choice of symmetric/assymetric encryption schemes
  • Encryption algorithm (AES, Blowfish, DES)
  • Choice of known protocols (e.g. SSL)
  • Key management and distribution
    • A single master key (if hacked, whole system is compromised)
    • Key per device (key distribution can be more difficult)
    • Protecting the key distribution channels
  • Will a potential hacker have easy access to sample device(s)? E.g. consumer product such as X-box vs a box locked in a telephone exchange. It's harder to protect against hacking if the hacker has physical access.
  • Human factors—social engineering etc.
  • A system is only as secure as its weakest link.

I suggest you read Bruce Schneier's material for starters.

淑女气质 2024-08-12 04:04:26

OAuth 绝对是一个考虑因素。除此之外,您可能还需要考虑 WS-Security。通过通过 Web 服务进行传输,您可以保持所有内容与平台和语言无关,并且添加 WS-Security 意味着加密和解密位于应用程序层(端到端)。因此,只要您相信消息一旦离开发件人就是安全的,您就知道它们将保持安全,直到客户端实际收到消息(这意味着它不会被服务器解密然后传递给客户端) /receiver,但在接收应用程序收到消息之后)。

因此,基本上您可以使用 OAuth 来保护/验证各种应用程序,并使用 WS-Security 来保护它们之间传递的消息。

OAuth is definitely a consideration. In addition to that, you may want to consider WS-Security. By transmitting via a Web Service, you keep everything platform and language agnostic, and adding WS-Security means that the encryption and decryption are on the application layer (end-to-end). So as long as you trust that the messages are safe once they leave the sender, you know that they will stay safe until the client actually receives the message (this means that it won't be decrypted by the server and THEN passed to the client/receiver, but AFTER the receiving application has the message).

So basically you would OAuth to secure/authenticate the various applications, and WS-Security to secure the messages passing between them.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文