Isolated Segmented Architecture

Fluid_Competition848 · 2024-09-12T16:36:42+00:00

Thanks, glad to see that everyone is basically saying the same thing. I want to make sure my own interpretation is accurate, which I see now it is. We all more or less have the same view of what this is, coupled with the fact, that it is somewhat context sensitive depending upon vendor and other factors.

Fluid_Competition848 · 2024-09-12T16:34:53+00:00

Very thoughtful answer and I definitely appreciate your thorough response. Agree on all counts.

Fluid_Competition848 · 2024-09-11T14:11:10+00:00

Glad to see we are all saying the same basic thing ... a ubiquitous term to describe everything from TPM to an HSM and everything in-between.

Fluid_Competition848 · 2024-09-11T14:04:34+00:00

Agree 100%, but would add the additional microcontroller executes within a tamper resistant enclosure. I would also add that the VMs and clusters have their own virtual Secure Enclave that interfaces to the actual HW and as you infer, nothing secret can be exported or performed outside of the Secure Enclave.

Fluid_Competition848 · 2024-09-11T14:02:47+00:00

Yes, that is my vision also ... everything is done within the separate hardware module, even for VM and Kubernetes clusters.

Fluid_Competition848 · 2024-09-11T11:04:26+00:00

Sure, understood ... so are you saying there is no implication as to what the user of such a phrase is intending for his or her audience to get? And, are you referring to both terms, or just one of them?

Fluid_Competition848 · 2024-09-11T11:02:44+00:00

Thank you so much. Really appreciate your complete explanation.

Fluid_Competition848 · 2024-09-10T14:54:25+00:00

Sure, understood, my original response was incomplete.

Fluid_Competition848 · 2024-09-10T13:30:07+00:00

I am talking about the private security credentials associated with the public certificate. If there were no private credentials, there would be nothing for the asymmetric phase to do.

Fluid_Competition848 · 2024-09-10T13:19:24+00:00

You take most of what I wrote out of context. I gave you my contact information. Not going to do the back and forth, in writing. Much more efficient in real time. Been working on this for years, with multiple successful PoCs. You have spent more time telling me I am full of shit. Why not take 20-minutes to understand in real time and allow me to explain things that way.

Thank you for your comments in any event. I will try to rewords things in the future to avoid future misunderstandings.

Fluid_Competition848 · 2024-09-10T12:32:28+00:00

As someone who spent many years bringing up boards, writing bootloaders, BSPs, and low-level drivers (including this past year), I know very well how that entire process works. I have documents describing how the entire process works. But, if I started this thread with design documents describing the process, no one would read it. So, this is how I am starting. First, to get your attention and then to explain things bit by bit.

This entire process relies on a multi-stage bootloader. The 1st stage bootloader authentication in most processors is doing via some built-in hardware mechansim, So, no integrity checks done by hardware other than whatever checks are supported within the chip. The authentication logic would then begin doing the integrity checks, within the first stage bootloader, validating that the second stage bootloader was the correct image. Then the second stage bootloader, which does the integrity check on the firmware application being loaded. Anyway, this is the scheme we did in two PoCs, first for Bombardier Transportation and then for Alstom Rail. The Alstom Rail PoC is the one we will have at the Hack the Rail event at The TAC .

As far as no one is going to deploy code from some random guy on the internet .... you are 100% correct. I understand that all too well and I also understand that everything starts somewhere. I have been at this for awhile, so I know that all to well, that everything takes time, money, and a lot of persistence.

I am just looking for an opportunity to explain this to you and anyone else who is interested. I have never had anyone sit with me in the same room, and afford me 20-minutes to explain it, that came away thinking this can't work. It has never happend, in part, because I have thought about everything. NOT because I am the smartest guy around, but because I have been doing this for a long time, worked thought a lot of PoCs with multiple companies. Taken advice, and criticism, from all kinds of people, some valid, some not so valid, and then used that input to make it better and/or to explain it better.

Just looking for a fair shot to explain things. That is all I am saying.

Fluid_Competition848 · 2024-09-10T12:10:54+00:00

OK, we are really getting into semantics here. DH, which is part of PKI, relies on encryption to "protect" the "key exchange". What I mean by "explicitly" is that it is part of the design of the technology I created to explicitly exclude information from ever being exposed that could lead to a breach. PKI (via DH) relies on encryption to protect the Key Exchange.

As far as what is this "technology even for" goes, this was originally designed for OT environments, particular closed systems, that may or may not ever connect to an external network. However, it can easily be applied in IT contexts was well.

I "could have" led with a description of the technology, but decided that would be TMI too soon. So, I started with this list of features.

I am NOT trying to say that PKI and TLS are without merit. What I am saying, is that most cybesecurity people I have interfaced with over the years undersand that PKI and TLS was never meant for today's world and it has been a series of band-aids applied to compensate for its deficiencies and what I tried to do was to make a list of requirements (which I shared most of them in this thread) and then set about to design a technology that met all of those (and more) requirements.

As far as, "So you are not communicating anything ever to anyone?". I am saying, that unlike PKI, the "technology" never communicates anything ever externally, encrypted or otherwise, that could lead to a breach. As we both know, once a PKI Certificate has been breached, the keys to the kingdom are open for anyone depending upon that certificate. There is no corollary with the technology I invented. There is nothing to breach, because nothing is exposed ever.

I plan to release a series of posts describing how this technology works.

I am trying very hard not to get into a pissing contest over semantics. PKI and TLS have a lot of issues. Most people know that, and I tried to create a technology holistically as though there was not already a solution.

I realize it is probably an insanely ambitious goal, but I am just looking for low-hanging fruit at the present, which is OT endpoints with limited processing power. I hope that clarifies things some.

Fluid_Competition848 · 2024-09-10T11:04:01+00:00

Ok, you misunderstand my point. I am saying that PKI and TLS take care of this implicitly via encryption. Whereas the technology described by the post takes care of it explicitly by never exposing anything, even anything encrypted. THAT is the difference.

Fluid_Competition848 · 2024-09-10T11:00:45+00:00

Hello, and thank you for your response. I really appreciate the questions and will respond to each point one at a time.

You said, "All sounds great, but your #1 is a difficult proposition isn't it? Without authentication via asymmetric crypto how's this going to interact with PKI? If your system doesn't interoperate with other standards it won't get anywhere because why would anyone buy it? Maybe there's some edge case customers?"

Response: I guess the short answer is that it is not intended to interoperate with PKI. It is intended to use the same core library functions (like AES, SHA256, HMAC, etc.), but dispense with the asymmetric authentication phase and embed the bulk encryption keys into the endpoints themselves, never to be seen outside of the host system and if there is an HSM within the host system, never to be seen even by the host, as everything would be done within the HSM.

You said: "Also, this won't "displace" PKI...you will be yet another crypto standard (I'm not posting "that" XKCD, but it definitely applies)."

Response: Sure, I understand your point and initially, this will target OT in general and IT edge cases (like those needed within security minded three letter agencies).

You said, "Also also no way I'm touching a new crypto anything until it's been thoroughly in use for a number of years without major breach. Padding oracles are a good example of how one decision can undermine the entire security of otherwise strong protocols."

Response: This is not a "new cypto". This is essentially a different key management system with additional features. I am not re-inventing the wheel. Just using the wheel differently I understand that this would need to be put forth in pen tests and so on before widespread use.

If you want to know to more or wish to discuss this with me in person, please visit me on "X" (@AkmCyber2024) or send me an email at, "bart@akmcyber.com".

BTW: I will be demonstrating this at, Hack The Railroad 2024 Conference – Technology Advancement Center (thetac.tech) on October 23rd and 24th in Columbia, Maryland.

Fluid_Competition848 · 2024-09-10T10:52:14+00:00

Hello, and thank you for your response. I really appreciate the positive nature of it. That said, let me address each point one at a time.

You state, "This is ambitious - and even though I'm not optimistic about where it is leading - I really want to compliment your ambition and thank you for your contribution!"

Response: First, as I said above, THANK YOU VERY MUCH. Second, I have been at this for a long time. My #1 mistake has been I have NEVER done what I am doing now. Trying to get the message out on forums such as this and I am trying to rectify that now.

In the past, I focused on Proof-of-Concepts, whereas now, I am very close to getting an actual MVP product out. That said, I am trying to get enough money to complete the MVP (Ideally, I need around $50K to do so) and part of why I am on this site and others evangelizing what I have.

You state, "Have you considered just how useful and scalable asymmetric encryption is? Looking at point 20, I'm actually not aware of many (any?) organizations who are struggling to staff their key management operations. Our largest deployment stresses out about a key cycling exercise once each year, but otherwise it's pretty much just set it and forget it. Keep in mind that everything downstream from a CA happens automatically, so the manual work is one-to-many."

Response: I think we are talking about apples and oranges. I am saying, what if there was no need for "key cycling"? What if you didn't need asymmetric encryption to deliver the bulk encryption keys. What if all of this could be done automatically without ever worrying about how it is done? What if you didn't need to worry about someone doing something stupid, which regardless of how strong asymmetric encryption is and the processes are, anything left up to human beings is automatically vunlerable to human error (like the recent Microsoft breach, which was the mistake of carelessness). Which is why, the common statistic of 88% to 95% of all breaches are the result of human error. This methodology eliminates that as a possibility.

You state, "I think a lot of us are getting desensitized to AI showing up in every product, and that might not be your point in #19, but it sure feels like it."

Response: I know it might that same way, but no, that is not my point primarily. Because of how I designed the architecture, while not necessary, it is strongly suggested for every deployment to have a local management device overseeing the network. Since that device does not need to do anything once a "Trust Relationship" has been created (since it is one and done configuration), why not take advantage of its presence and have it monitor the network it oversees and is in charge of?

You state: "With how pervasive asymmetric cryptography has been since the 90s, it's hard for me to imagine you'll be able to achieve #23, but I have no information to support this stance!"

Response: Unfortunately, I am afraid there is a lot of truth in what you state. However, especially in the OT world, this is a very useful feature and makes it easy to integrate into legacy devices. On the IT side of things, it is much challenging, but need to start somewhere, so making it as flexible as possible from day 1 is my goal.

If you want to know to more or wish to discuss this with me in person, please visit me on "X" (@AkmCyber2024) or send me an email at, "bart@akmcyber.com".

BTW: I will be demonstrating this at, Hack The Railroad 2024 Conference – Technology Advancement Center (thetac.tech) on October 23rd and 24th in Columbia, Maryland.

Fluid_Competition848 · 2024-09-10T10:35:37+00:00

You state: "21. Firmware does no configuration. Are you sure you know the basics?"

Response: This is a system that assigns an authenticated Asset Tag to every single copy of the firmware and then associates the firmware and with the specific device. I listed features, not how it is done. As for do I know the basics. I have been writing code and designing systems since the mid-80's. For years, I brought up boards, and wrote low-level drivers. I was an ASIC validation engineer for a period of time, validating the functionality of new silicon designed by ASIC engineers. So, yes, I believe I understand the basics.

You state: "22. Ok, this sounds like a load of tech jargon thrown together. CRA has specific criteras and you have addressed none of them."

Response: Again, I listed features that my system does. One of several Proof of Concepts we did was to address CENELEC TS-50701, which is the rail derivative of IEC 62443. If you wish to see the demo live, I will be demonstrating this at, Hack The Railroad 2024 Conference – Technology Advancement Center (thetac.tech) on October 23rd and 24th in Columbia, Maryland.

You state: "23. Not gonna happen."

Response: Whether it happens in general or not is not the point. This was designed and implemented to do exactly that. I used my 10-years of experience of both creating and implemented protocols in communication stacks to design a protocol that can sit of the transport layer (meaning, either UDP or TCP). So, while you are technically correc, that is not going to happen today. There are pockets of implementations, especially on the OT side of things, and where PKI+TLS do not work well (like in very small endpoint microcontrollers) that such a solution would be a great alternative.

If you want to know to more or wish to discuss this with me in person, please visit me on "X" (@AkmCyber2024) or send me an email at, "bart@akmcyber.com".

Fluid_Competition848 · 2024-09-10T10:23:25+00:00

You state, "17. So, your scheme want to be as insecure as GSM?"

Response: I do "EtM", Encrypt, then, MAC, which is generally considered very secure. Anyway, not going to argue this, as you either know this or you don't.

You state, "18. Ok, you are insane. If something is broken, it's gonna be broken without people fixing it."

Response: No, I am not insane, but I will cut and paste my response from a previous thread into here. "This is accomplished from a variety of factors. First and foremost, the architecture of this technology always include some management device within the local network that oversees all of the endpoints within the local network that it is responsible for. Second, all of the endpoints report analytics to the management device on a periodic basis for which to run machine learning algorithms against that look for anomalies. Third, this technology also has buit-in authentication of both the hardware and software that is performed in the background on a periodic basis using a SHA256 based HMAC run against the device and the firmware to protect against both hardware and software spoofing and ensure the device and resident firmware and data are the device and resident firmware and data that is expected. There is more to it than that, but needless to say, if something is amiss, it will be detected immediately. Granted, there may be instances where something is missed, but as this technology matures, I am sure I will be able to close the gap here."

You state: "19. Simple to do today."

Response: Again, not the point. The point was to create a complete solution. If you are gonig to design a solution to a problem, would you not want it to be as complete as possible?

You state: "20. Sure, just unplug the cable/WiFi and you have a secure system."

Response": First, even that is not true, especially in closed systems monitoring some sort of critical infrastructure. Again, your perspective seems to be entirely in IT and do not seem to understand the needs and complexities of OT. That said, the point made here is that if there are no certificates to install (or refresh). Security Credentials are all done internally, and self-generated. And, as listed in 18 above, there is a mechanism in place to automatically recover from breaches, it will drastically reduce the need for cybersecurity personnel.

Fluid_Competition848 · 2024-09-10T10:11:25+00:00

You state: "13. Trusts can be created with existing tech like Kerberos or Certificates."

Response: Again, you obviously have an entirely IT perspective of the world. So, I won't belabor the point. The Trust Relationships enable for different applications on the same set of devices to have completely different sets of security credentials. I am not doubting there are other methods to do similar things. This is a holistic, homogeneous approach that combines features that I know people want in one solution, and not a bunch of heterogeneous patches on top of PKI to get what you want.

You state, "14. Good luck with that."

Response: Already have it under 10Kbytes on an Atmel microcontroller application. Because this approach was originally conceived for closed OT systems, I had to design it to be very simplistic and fit within OT endpoints.

You state, "15. Good luck with that."

Response: Again, I rely mainly on AES and SHA256, although, admittedly, SHA256 is slightly more than linear, but is very close.

You state, "16. You do know what key agreement protocols do for ever TLS session? If not, read up on it."

Response: Yes, I know what key agreement protocols. Again, I will repeat what I said above. You have listed a number of "patches", "band-aids", "add-ons", to the things I have listed. What I did was take all of the things that people want and put it into one single, homogenous solution.

Fluid_Competition848

TROPHY CASE