Add support for key sources using ETSI 014 #36
Open
haroldbruintjes wants to merge 15 commits into
Open
Conversation
Import was unused and from a more modern version of Java than configured.
- Replace the block index in QNL requests and responses with an arbitrary string. - At the QLL level, encode the block index, offset and length as a string (simply by concatenating the values). - Rework the QLLReader interface to make use of key identifier strings. Keys are provided in binary form directly (though the file-based backend encodes the as hex still). - Remove the write function from the QLLReader interface, it the coming architecture that is an implementation detail. Keys are read and written directly as binary data, the backend still stores them hex-encoded.
Each time an OTP key is requested, pull one from the underlying QLL reader and attach its ID to the request message. On receipt, use the same ID to fetch it from the other side and decode the message payload. Removes the KeyListener interface from OTPKey as keys are now retrieved on demand.
Extend the route configuration parser to support specifying connection details for a KME that will provide keys via the ETSI API. Notably the address is now a nested property, next to the (optional) KME details.
Implementation of QLLReader that works via the ETSI API/specification. It simply requests a new key of fixed size, or uses the ID passed via the key router to retrieve it on the other end.
Add switch to choose between legacy and ETSI QLL interface If legacy is specified, enable the site agent and trigger a start hop, and use the CQP infrastructure. Otherwise, use the ETSI KME configuration.
If legacy mode is not enabled, do not parse the QKD configuration files (site agent configuration and link configuration), making those files optional.
LSRP traffic is fairly noisy, so reduce the log level.
If a message was seen before, ignore it completely. This fixes packets propagating indefinitely in case of certain cycles.
Multiple routes can be configured, and if one fails the others might still be valid. Allow loading to fail (but log the error) so the application may continue.
Some ETSI servers have a broken TLS session resumption, so bypass that by invalidating all sessions after each operations. Use a networkInterceptor to achieve this.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR adds basic support for devices implementing the ETSI 014 REST interface as key source in the QNL key router service. In summary:
A bug was also fixed in the LRSP handling that prevent it from dealing with cycles properly.
The ETSI client simply requests entire key blocks at once. It is possible that a simulator/device does not support keys of that size, in which case the key block size should be reduced in the configuration (possibly to just a single 32 byte key).