Live data from Hacker News

ControlMQ – Secure communications for control system applications

cognoscentisystems.com

11–20 of 34 posts

Re: ControlMQ – Secure communications for control system applications

#11
post #8

They have re-implemented entire network stack above IP layer. They start from raw IP (protocol 99), and then added "AES, SHA, RSA, and elliptic curve". So you cannot use TCP/UDP/TLS/QUIC -- they are too insecure; instead let's have a bunch of code designed by unknown people, likely with not professional crypto experience, and not verified by anyone. Riight....

Yes, we have found that the set of Internet Protocols were designed before the kind of security we expect today were appreciated. You are correct that we are not professional crypto people. But, crypto is just the starting point for cybersecurity that is a necessary but not sufficient condition for a secure system. What we did was start with crypto, and related technologies like cryptographic hashes, secrets, etc. and built a secure messaging system using the principles mentioned above. This has so far shown itself to be highly successful.

Hi, The reply buttons have apparently been disabled. I guess cybersecurity is too controversial for HN ;)

I will reply here instead.

@theamk

1) UDP leaks information, thereby violating the C in CIAA. TCP is subject to the SYN resource exhaustion attack, and is connection oriented which is brittle. Both are vulnerable to packet replay attacks, which is a particularly troubling problem for controls. 2) The pen testers that evaluated our technology we believe to be highly competent. We are open to having the pen testers (US only) of your choice test our technology.

@pritambaral

Yes, see the quotes on our website. And we do in house testing as well. We are happy to have pen testers (US only) try to defeat the system.

Re: ControlMQ – Secure communications for control system applications

#13
post #3

How is it different from zeromq?

Great question. Some issues with ZeroMQ:

It uses TCP/IP which has security issues that can lead to resource exhaustion. The SYN is sent but the sender never acknowledges the reply, so the server simple keeps the resource reserved waiting for the sender to get back to it.

It leaks information in the message even if fully encrypted. Just the size of the message in a control system usually tells you what it is.

It doesn’t protect against packet replay, which is particularly serious for control systems. An attacker can just sniff some messages, which are fully encrypted, authenticated, validated, etc., and save them for later. Then, when needed, resend them to reenact the former actions. E.g. “open valve” message is captured. Later, the “open valve” message is resent to, once again, open the valve, even though the legitimate user may have closed it and expect it to be closed.

Re: ControlMQ – Secure communications for control system applications

#14
post #5

Wow. This is a 30 day trial offer over supposed "hardened controls". Pardon my skepticism, but proof or GTFO. I already have access to ZeroMQ, RabbitMQ, Mosquitto, Californium, and plenty more. And they all are open source under reasonable licenses. So can someone please tell me: 1. Why should I trust your claim of security? 2. Why your product is worth money when I can go Open Source for free? 3. Why should I deal w…

BTW, why did you flag this post with out giving me a chance to reply?

Re: ControlMQ – Secure communications for control system applications

#15
post #11
post #8

They have re-implemented entire network stack above IP layer. They start from raw IP (protocol 99), and then added "AES, SHA, RSA, and elliptic curve". So you cannot use TCP/UDP/TLS/QUIC -- they are too insecure; instead let's have a bunch of code designed by unknown people, likely with not professional crypto experience, and not verified by anyone. Riight....

Yes, we have found that the set of Internet Protocols were designed before the kind of security we expect today were appreciated. You are correct that we are not professional crypto people. But, crypto is just the starting point for cybersecurity that is a necessary but not sufficient condition for a secure system. What we did was start with crypto, and related technologies like cryptographic hashes, secrets, etc. an…

Glad to hear from authors!

Question 1: So how is your solution better than UDP/QUIC or TCP/TLS? Yes, you have to properly tune and use protocols, by padding the data properly, and by setting up DDOS mitigations. Still, it will be much less work that writing a new protocol from scratch, and it will be better than your protocol in every single aspect.

Question 2: What do you mean "highly successful"? I did not see anything in the whitepaper (but I have not read it very carefully), and the website has two quotes from hilariously incompetent pentesters. Do you have any other evidence of success?

Re: ControlMQ – Secure communications for control system applications

#16
post #11
post #8

They have re-implemented entire network stack above IP layer. They start from raw IP (protocol 99), and then added "AES, SHA, RSA, and elliptic curve". So you cannot use TCP/UDP/TLS/QUIC -- they are too insecure; instead let's have a bunch of code designed by unknown people, likely with not professional crypto experience, and not verified by anyone. Riight....

Yes, we have found that the set of Internet Protocols were designed before the kind of security we expect today were appreciated. You are correct that we are not professional crypto people. But, crypto is just the starting point for cybersecurity that is a necessary but not sufficient condition for a secure system. What we did was start with crypto, and related technologies like cryptographic hashes, secrets, etc. an…

> ... built a secure messaging system using the principles mentioned above.

> This has so far shown itself to be highly successful.

What do you mean by this? Can a system be "highly successful" at being secure without having been targeted, or have you actually hired testers and/or auditors to attack/study the system?

Re: ControlMQ – Secure communications for control system applications

#17
post #13
post #3

How is it different from zeromq?

Great question. Some issues with ZeroMQ: It uses TCP/IP which has security issues that can lead to resource exhaustion. The SYN is sent but the sender never acknowledges the reply, so the server simple keeps the resource reserved waiting for the sender to get back to it. It leaks information in the message even if fully encrypted. Just the size of the message in a control system usually tells you what it is. It doesn…

Note: that answer is mostly incorrect.

1. While simple TCP/IP implementations have SYN flood issues, there are plenty of ways to mitigate them, including SYN cookies and third-party firewalls and load balancers. In fact, the SYN flood mitigations are so good, that most modern attacks are either raw traffic, or higher-level connections.

2. TLS pads your messages to block size (for example, 16 bytes). If your message size varies by a bigger amount, just pad all of your messages manually. This takes 2 lines in modern scripting languages. No need to switch to all-new suite.

3. This is just outright wrong. If you have messages which are "fully encrypted, authenticated, validated", then it means you run ZeroMQ with either TLS or CurveZMQ. Both of them have full protection against replay attack.

Re: ControlMQ – Secure communications for control system applications

#18
post #11
post #8

They have re-implemented entire network stack above IP layer. They start from raw IP (protocol 99), and then added "AES, SHA, RSA, and elliptic curve". So you cannot use TCP/UDP/TLS/QUIC -- they are too insecure; instead let's have a bunch of code designed by unknown people, likely with not professional crypto experience, and not verified by anyone. Riight....

Yes, we have found that the set of Internet Protocols were designed before the kind of security we expect today were appreciated. You are correct that we are not professional crypto people. But, crypto is just the starting point for cybersecurity that is a necessary but not sufficient condition for a secure system. What we did was start with crypto, and related technologies like cryptographic hashes, secrets, etc. an…

Reply to your message edits:

> 1) UDP leaks information, thereby violating the C in CIAA.

Which information? Properly encrypted UDP only shows destination IP and port number. Your protocol shows destination IP and protocol number (99) -- since very few people use it, protocol 99 is as distinct as UDP port.

Moreover, if you are concerned with UDP port leak, you can just use a random destination port on server, or masquerade as some other UDP protocol. There is no such option with current ControlMQ system

> TCP is subject to the SYN resource exhaustion attack, and is connection oriented which is brittle.

You do know about SYN cookies, right? And you know that SYN flood is easily defeated now -- for example, out of 5 most significant DDOS attacks in 2016 (https://www.tripwire.com/state-of-security/security-data-pro...) , none used SYN flood.

> Both are vulnerable to packet replay attacks, which is a particularly troubling problem for controls.

Any control connection should use encryption. Every popular encryption method (including TLS and QUIC) protects against replay attacks.

> 2) The pen testers that evaluated our technology we believe to be highly competent.

Well, all I have is front page quote, and I see the words "We were unable to [...] observe [...] the message traffic" and "TCP and all the UDP ports only list that they are open/unfiltered". This apparently means they could not even use wireshark to observe the IP message traffic -- they just ran "nmap" and found not ports. This is pretty sad for a pentester. I would expect to see mentions of DOS attacks and fuzz testing.

For example, what happens if I just start sending random packets to your daemon? How many packets per second it can handle before it fails over? What if I compromise a client, extract a session establishment key from it (assuming you have one), and start to establish new sessions? how many will your server handle before failing?

Re: ControlMQ – Secure communications for control system applications

#19
post #9
post #5

Wow. This is a 30 day trial offer over supposed "hardened controls". Pardon my skepticism, but proof or GTFO. I already have access to ZeroMQ, RabbitMQ, Mosquitto, Californium, and plenty more. And they all are open source under reasonable licenses. So can someone please tell me: 1. Why should I trust your claim of security? 2. Why your product is worth money when I can go Open Source for free? 3. Why should I deal w…

Thanks for your thoughtful comments. Yes, I can understand your skepticism, and that is a good sign that you don’t believe whatever folks are just saying. That is particularly good in the cybersecurity field as claims that are unsubstantiated are often made. The problem with cybersecurity is that you can’t prove a negative proposition. That is, it’s not possible to prove that a system will never be hacked. That said,…

I flagged it because I saw this as a hand-wavey "magic code" combined with a website filled with market-ese. I've been long enough in this industry to smell this at a distance. But I see the [DEAD] was rescinded. Ill be willing to rescind my flag since a rep of the company is here (you).

_________________________________

> Yes, I can understand your skepticism, and that is a good sign that you don’t believe whatever folks are just saying. That is particularly good in the cybersecurity field as claims that are unsubstantiated are often made.

It really has to do with multiple things here. First, is a new crypto implementation. That sets of major alarms with me, no matter who writes it. Especially so being infrastructure, this should be open source and publicly accessible for review.

Secondly, you're using a new IP protocol. Full stop. This should be absolutely IETF standard, reference design, full engineering review, kind of code. I see none of that. I would get not having gone this route if you're trying to get a new protocol spun up with a reference design. I'm thinking of IPFS, where everything's open and done in public on GitHub and IRC. In my opinion, they're going on the route of getting an IETF standard in a different way (of utmost transparency and collaboration).

_________________________________

> The problem with cybersecurity is that you can’t prove a negative proposition. That is, it’s not possible to prove that a system will never be hacked. That said, there are ways of increasing the cybersecurity of a system to the extent that a compentent attacker, i.e. a nation-state actor, will need to commit significant time, personnel, and resources to attempt to mount a serious attack. Most likely they will look elsewhere to attack rather than the network interface that our product protects.

You want to play this game? Sure, I'll bite. How do you know you don't have a protocol error baked in at the definition of how your stuff works? Sure, you all were smart enough to build it, and some pentesters you hired said it was OK. The basic idea with RFC's was that everyone, collectively across the world could collaborate on how a protocol would work, or not. Failure domains could be identified and caught before a full standard was made. Have there been errors in these base protocols? Sure have. But they collectively have been fixed.

How do you plan to have peer review of your protocol, let alone your implementation? Hope and prayer, I guess. And when it comes to infrastructure, that's nowhere near good enough for me. I need an open, peer reviewed protocol with a clear reference example. You can build your middleware and I'd consider purchasing that for value-add. But "No Way" with regards to the actual protocol.

_________________________________

> As to your specific questions: 1) The only way to evaluate the cybersecurity of a system is through penetration testing. We’ve had several highly competent teams evaluate our technology and have failed to defeat it in any way. You should have your own penetration test teams test all of your systems before you put them into production, and then periodically continue to test them for vulnerabilities. That said, no system is perfectly secure. But, we’ve been accepting systems with poor cybersecuity for quite a while, it’s time to raise the bar on what is acceptable cybersecurity.

Absolutely NOT. The other way to prove cybersecurity of a system is to prove it. For example, I can write functions in Erlang that I can prove are mathematically correct. I can show any input and its related output. I can probe the state of the system and inspect it at any time. And I can functionally understand it from a formal aspect.

Your claim is "Oh just pentest it". That's what you have to do for a black box, but that only _delays_ major problems. For example, there's controllers on Hard Drives. Only the HD makers know about them, so nobody can do anything, right? Wrong. Enter Sprite_TM http://hackaday.com/2013/08/02/sprite_tm-ohm2013-talk-hackin...

This person figured out how to control all 3 ARM chips, with unknown instruction sets, from just probing, hacking binaries, and poking at stuff. Black boxes like what you're peddling WILL get hacked. And if they're white hats, they will likely tell you. Or, exploits will end up on random Tor auction site.

The middle ground is a published protocol and reference code to bootstrap. It doesn't have to be feature-laden. But its the foundation of proper Networking code. And instead, hand-waviness is claiming "We hired some hackers, so we're good". That doesn't cut it, especially for critical infrastructure.

_________________________________

> 2) You are free to choose open source or any product. The problem with current technologies is that they were designed before the kind of high-level cybersecurity we expect today was understood. These existing technologies are wed to their current protocols which can’t be patched to make them more secure. Only a redesign from scratch will do that, which is tantamount to abandoning their current protocols.

https://xkcd.com/927/

Oh, also, MQTT specifies absolutely nothing about payload type. Technically, a publish to a MQTT broker can be a cryptographic payload, a DVD image, a boolean, or anything. The spec allows anything to be put in as a publish. From there, it would be trivial to extend MQTT to require a cryptographic signature. Mosquitto supports plugins that could verify data authenticity.

And there's also RabbitMQ (AMQP) with forward-and-store. Similar extensions to it are available as plugins. What I see here, is a strawman of "Something something security" and pushing an untested, unfounded, unknown protocol for IoT and industrial devices, and operating on the "Hope and Prayer" principle.

_________________________________

> In a sense, cybersecurity is a conspiracy of trust. Without trust there is no security.

I disagree with this as well. I shouldn't have to "Trust". That's what "Proof" is about. Proof would allow me to accept the code, even if you are a bad actor (I don't believe you are, I only think your goals are misguided). If the foundations are solid, it wouldn't matter what you say, if anything.

Re: ControlMQ – Secure communications for control system applications

#20
post #18
post #11

Earlier quoted context omitted.

Yes, we have found that the set of Internet Protocols were designed before the kind of security we expect today were appreciated. You are correct that we are not professional crypto people. But, crypto is just the starting point for cybersecurity that is a necessary but not sufficient condition for a secure system. What we did was start with crypto, and related technologies like cryptographic hashes, secrets, etc. an…

Reply to your message edits: > 1) UDP leaks information, thereby violating the C in CIAA. Which information? Properly encrypted UDP only shows destination IP and port number. Your protocol shows destination IP and protocol number (99) -- since very few people use it, protocol 99 is as distinct as UDP port. Moreover, if you are concerned with UDP port leak, you can just use a random destination port on server, or masq…

Good points.

The port number typically indicates a service that is publicly known and repeatable. This is leaked information, as each service will have a unique port number. The IP protocol of 99 is used for all communications so no differentiation of network traffic can be made using this information.

SYN cookies can be a solution, but it has limitations, and to overcome those limitations requires changes to the TCP protocol. It is also preferable not to use TCP for controls in order to avoid the coupling caused by connections. The network between components may also be unreliable thus causing the need for regular reconnections.

Replay attacks protection by TLS, etc uses sequence numbers which expects a continuous connection. There is the setup phase that must be taken into account and then the entire series of packets from that point on can be replayed. The goal is to run on unreliable networks so connections would constantly need to be reestablished.

We consider DOS attacks to be attacks on the network rather than the component.

The number of packets/sec that the daemon can handle is computer resource determined. But, >1000/sec is typical in our testing on commodity H/W. It has never failed due to load in thousands of hours of testing.

If a client (first peer) is compromised then it can send any message it wants to the second peer with which it is configured to communicate. But, only properly formed, valid range messages will be accepted. Let’s say that the receiving component controls a motor that has a valid engineering range of 0 -1000 RPM. If a nefarious command came in to spin to 2000 RPM that would be rejected. The server (second peer) is not connection based so it will handle whatever packet arrive at the rate it can, and drop the rest on the floor.

So, overall we believe it is simpler and less error prone to use our protocol then set up all these complicated extra configurations.

Post reply on HN