EspañolIn November 2021 REDCOM and AFCEA hosted a webinar where the current state of the Zero Trust Architecture at the tactical edge was discussed along with our newest solution, ZKX. We had lots of audience questions, but we weren’t able to get to them all in the allotted time. So, we decided to form this FAQ. If you have other questions or would like a more detailed conversation, please reach out.
What kind of performance impacts would a ZT framework have? Would it create a disadvantage in some scenarios?
Even with 10 challenge rounds, the Tx/Rx bandwidth required is in tens of bytes and fractions of a second. We will perform stress tests on our own server in the SIGMA XRI as well as other COTS processors and publish a more detailed report as the product matures
Building ZKX bottom-up, how do you plan to deploy it to multiple devices on the tactical edge and how do you take care of legacy systems? How do we get your manuscripts?
We have built ZKX to operate on any platform that can run & execute code. This architectural agnosticism combined with its low throughput requirements (on the order of kilobits) allows us to operate on a vast variety of different endpoints, servers, platforms, etc. Please reach out to have a more in-depth conversation and receive some more technical materials!
How do you achieve that unique output? Random algorithm?
Yes. Random zero-knowledge proofing elements are injected into every user response to an identity challenge. It is a fundamental part of the ZKP protocols.
Is there a NIST certification like FIPS for this style of authentication? If so, has the product been certified?
There is a NIST certification for identity & authentication solutions, namely NIST SP 800-63 (Digital Identity Guidelines). There is no official process for certifying a technology against this standard (it is a self-asserted designation) but we have designed this technology to be compatible with the requirements of AAL3, the highest standard for digital authentication solutions. REDCOM would love to see a formal and definitive standard & certification body developed for authentication and identity solutions, and ZKX will be one of the first products in line to undergo that process, whatever it may look like.
Do you have a diagram that shows where ZKX sits within a tactical enclave?
Yes! We have several generalized architecture diagrams for how ZKX will look in a forward-deployed or tactical setting. Many of its details are left up to implementation or mission specifics, but the generalized diagrams will give you a feel for where in the ecosystem ZKX will reside. Please reach out to us and we can get those to you!
Isn’t the one-way function just asymmetric encryption? Are you removing symmetric encryption altogether? In the past, asymmetric was used to establish a connection while symmetric is used to communicate after to maintain higher performance that is not possible with asymmetric methods. Does this mean you will get a significant performance hit?
One-way functions are a fundamental component of asymmetric encryption, and there are many similarities between ZKX and more common asymmetric encryption techniques. ZKX will leverage any existing transport mechanism with or without encryption, so whatever transport security you require can still be implemented. In terms of protecting the authenticating data, users create responses to identity challenges using a public key-based system that also utilizes zero-knowledge proofs. Again, ZKX is not a transport protocol. Whatever safeguards you require over your data channels are free to remain. ZKX is a privacy-preserving, robust MFA system – other parts of the transaction like networking or policy governance are outside of its control.
How about implementing a biometric verification that is hashed and stored on-chain. The processing happens off-chain on the users’ device and is transmitted as a ZKP. That would eliminate the CAC.
ZKX can handle anything you throw at it. New cards, serial numbers, blood type — ZKX is agnostic to the methods our customers will use to manage their users and the databases defining them.
Do you think the Soldier will ever be required to authenticate themselves and devices when downrange? Most tactical systems don’t have an AD environment or AAA, historically they use local login only. How will ZTA address security for a tactical Soldier, one that is in the field and needs information now?
This is an interesting question and one that the enterprise (and industry, for that matter) are still struggling to answer. ZTA requirements have yet to be developed for tactical settings, but we envision the situation being like today, no AD or AAA, and no cloud connectivity. ZKX is designed to operate within even the smallest formations – users can authenticate themselves and their device(s) before detaching from garrison, and our zero-knowledge identity attestation will keep their user/device identity verified if there is connectivity to a computer platform taking care of the verification side of that transaction. ZKX operates on the order of 10^0 kb per round, so even the most degraded SATCOM links can still facilitate ZKX authentication.
We hear you say that we must not trust the user and not trust the device. That’s why you have all kinds of Zero Knowledge checks build-in. What about Identity? Why do you trust identities?
This is a good point, and worth reinforcing. ZKX assumes that your organization has already undergone its own identity-proving process (think like being provisioned your first CAC or bringing a birth certificate and electric bill to the DMV to get a driver’s license). ZKX does NOT stand up to these identities, just authenticates them. This was an intentional design choice in order to allow organizations to continue utilizing their own trusted identity processes. We are simply offering a newer, more secure, and faster way to prove those identities (via zero-knowledge MFA) which are defined by your existing onboarding processes for employees, guests, contractors, etc.
We’d like to understand the math you’re using in ZKX
Have your nerds call our nerds.
If you have further questions email us at sales@redcom.com