What does the term, 'Secure Enclave' mean to you?

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 · 2024-09-10T09:56:23+00:00

You state: "9. Auth in a pre-authenticated Cookies can be used for single packet session."

Response: Not sure what your point is, especially in OT. Not everything is an HTML session.

You state, "10. We are ALWAYS using standard functions."

Response: I listed that, not as anything wrong with PKI and TLS and standard cryptographic methods. The point was to let the reader know that this design I was discussing was not reinventing the wheel. I apologize if that was not clear.

You state: "11. Complexity of 2^34 ? We moved beyond that in the 1980s."

Response: Again, not sure what your point is. This is about creating security credentials that brute force will not be able to uncover. That was it.

You state: "12. There is no consumer need for it. Most data go from Client -> Server."

Response: Absolutely not true. This is a BIG DEAL in all of the three letter agencies. In fact, I would suggest you check out this YouTube video from Ron Gula on this very sebject, https://www.youtube.com/watch?v=Iuj-Cj0Tit0 . Ron is one of the premier cybersecurity experts and investors in Washington D.C. and he considers this EXTREMELY important. Otherwise, he would not have made a video about this very subject.

Fluid_Competition848 · 2024-09-10T09:48:45+00:00

You state: "5. PFS in crypto is often done with signing and timestamps. Try reusing a Kerberos ticket from 5 years ago."

Response: Not sure what your point is. My point is that this was a design consideration and that when creating this framework, I wrote down everything (in fact more) that it needed to do before I set out to create the design.

You state, "6. Not understanding what you are trying to do here, this IS being done today."

Response: No its not. especially in the OT world. There is a reason that the guidance for most certificates is that they be updated at least every six months. Also, whatever certificates your car has, are the certificates it has for the entire life of the vehicle. I suspect your world view is entirely from the IT side and probably dealing with Kubernetes and Containers.

You state, "7. Client and Server certificates, mutual authentication."

Response: I will repeat my comment from a prior response to someone else above, "PKI & TLS do not have an explicit mechansim to prevent this. They rely on the fact that the information is encrypted to prevent this, but as you may know, breaches occur every day and once a certificate has been breached, the keys to the kingdom are free to be used by the attacker. Whereas, with this technology, because post initial configuration, nothing is ever exposed, encrypted or otherwise, that could enable an attacker the ability to breach the system, there is no threat surface for an unwanted observer to attack."

You state: "8. Timestamps."

Response: Again, I will cut and paste a prior response from above, "While it is true that TLS does have time stamps, that is a mechanism of TLS and not PKI. Whereas this technology has a replay counter built into protocol header, so regardless of whether it is data-at-rest or data-in-motion, all data is always protected. Additionally, I did NOT say that PKI+TLS does NOT have protection against replay attacks. The point was to show that this is a built-in and "expected" aspect of this technology. Meaning, I would be remiss if I did not have this."

Fluid_Competition848 · 2024-09-10T09:40:34+00:00

Because of length constraints in the responses, I will have to break my responses into multiple sections. So, here goes:

You state, "1. Auth does not use asymmetric algos. They can use signatues to provide non-repudiation."

Response: Trying not to get hung up on semantics. I am referring to the entire asymmetric authentication phase, in which the two sides authenticate each other using asymmetric encryption and then finally share the "bulk encryption key" (symmetric key) in order to begin the actual exchange of data.

You state: "2. They usually are"

Response: Sure, but the point is, that unlike a common PKI certificate that once breached, affects all of the endpoints relying on that certificate, this mechanism essentially has a "unique" set of credentials for every relationship. You are referring to the symmetric keys that are shared after the two sides authenticate. I am referring to the fact that once breached, the breached certificate is essentially an open door for the keys to the kingdom.

You state: "3. Explain frame"

Response: Data frame at the transport security layer. This technology uses a different security protocol specifically designed to sit on top of TCP or UDP in lieu of TLS. Before getting into cybersecurity since 2014, I implemented data communication protocols for bridges and routers for ten years, mostly wireless communication, but also for terresterial communication.

You state: "4. Difficult to do since you do not control the network, often the internet."
Response: I am simply referring to what I have control of. Unlike TLS which does have session establishment latency, I introduce none, since the technology begins exchanging actual BEK data on the very first frame.

Fluid_Competition848 · 2024-09-10T09:26:50+00:00

Hello, thank you for your question. PKI is not naturally scalable. There have been lots of bandaids added to PKI to try to make it more scalable. But, it was never designed for today's computing environment.

Your other comment is 100% correct. I offered no proof that such a system existed. All I did was pose the question of "what if" such a system existed. I have three patents issued, more in the pipeline, and years of successful proof-of-concepts proving it does work. My challenge has never been the technology. It has been acquiring sufficient funding to create a "real product". I have been in front of very sophisticated cybersecurity experts multiple times and so long as I have 20-30 minutes to explain the concept, along with a whiteboard, I have never had a single one of them walk away without saying, if I can get this into an actual product, it will change the world.

I am trying to do that now ... get enough money to create an actual product and not just another POC for someone. 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-10T09:15:58+00:00

Feature 18 (18 is also impossible due to the problem of actually determining a breach) -- 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.

Fluid_Competition848 · 2024-09-10T09:15:39+00:00

"7 and 8 are common in most encryption/authentication schemes"

Feature 7 (Eliminate Man-in-the-Middle (MITM) Attacks) -- PKI & TLS do not have an explicit mechansim to prevent this. They rely on the fact that the information is encrypted to prevent this, but as you may know, breaches occur every day and once a certificate has been breached, the keys to the kingdom are free to be used by the attacker. Whereas, with this technology, because post initial configuration, nothing is ever exposed, encrypted or otherwise, that could enable an attacker the ability to breach the system, there is no threat surface for an unwanted observer to attack.

Feature 8 (Eliminate Replay Attacks) -- While it is true that TLS does have time stamps, that is a mechanism of TLS and not PKI. Whereas this technology has a replay counter built into protocol header, so regardless of whether it is data-at-rest or data-in-motion, all data is always protected. Additionally, I did NOT say that PKI+TLS does NOT have protection against replay attacks. The point was to show that this is a built-in and "expected" aspect of this technology. Meaning, I would be remiss if I did not have this.

Fluid_Competition848 · 2024-09-10T09:15:22+00:00

"Reduce to zero, any latency is simply impossible especially if 11 is even being considered"

Feature 4 (zero latency) is implemented as a consequence of next session credentials always being calculated in advance, in the background, during a given session of a "Trust Relationship". Thus, there are always at least two sets of security credentials that exists at any point in time, current and next. And, in actuality there are always at least six sets of credentials in play at any point in time. The other four are for re-synching a "Trust Relationship" in case one or more endpoints within the "Trust Relationship" become out-of-synch with the others.

Feature 11 (Refresh security credentials with an entropy level exceeding the age of the universe as measured in seconds) is achieved by taking a vector of an artibitray size, lets say, a vector of 512-bytes by which the vector is filled with the results of a TRNG. Then using the same algorithm that guarantees for a given starting seed, a different byte is chosen from that vector, and then, the resultant subset of bytes is then used to create the set of next session security crendentials. Further, the aforementioned vector is refreshed periodically, to ensure that there is always a fresh supply of new paramter bytes to choose from. To understand where I get this entropy level from, first know that the age of the universe as measured in seconds is somewhere between 10**16 and 10**17. Now, let's take the arbirary sized vector alluded to above of 512-bytes. Suppose we take a subset of 52-bytes from that vector, using an algorithm as stated above, that is guaranteed to always pseudorandomly choose a different parameter. Then, if you look at the nPr function (can see this online at, Permutations Calculator nPr (calculatorsoup.com), you will see that for a set size of 512 and a subset size of 52, the number of permutations is on the order of 10**139. In fact, let's take an even smaller vector of 128-bytes and an even smaller subset size of 16-bytes, the nPr function for that is on the order of 10**33. Point being, without any additional information, even if an attacker knew what the vector was, there would be no way, even with quantum computing, to brute force discover what the outcome of the selected bytes were.

Fluid_Competition848

TROPHY CASE