The Egendata solution uses standard algorithms for all encryption and signatures.
The Operator acts as the single point of contact for all Services and Applications integrated with the Egendata solution. It is highly recommended that all communication channels with the Operator are established using the TLS protocol (although not enforced).
All Services or devices that establish connectivity with the Operator verifies the validity of the Operator’s TLS certificate to ensure that it’s issued directly/indirectly by a trusted Certificate Authority.
Thus communication with the Operator is considered trusted and secure.
Due to the Egendata Application not acting as webserver, it is unable to publish its own public key(s). Therefore, recipients are unable to verify the authenticity of Messages issued by the Application. Instead the Application provide its own public key(s) directly embedded in the transmitted message, however this is not sufficient to prove authenticity of the message.
It is, however, possible for the Operator to assert that an account uses one and only one key for signing
its communication. This is currently not enforced.
There is one exceptional case when the App needs to establish a new connection with a Service. The CONNECT_INIT message originating from the App is not transmitted via the Operator, instead it’s directly transmitted to the Service’s /events endpoint. This outgoing CONNECT_INIT message and response could potentially be tampered with if the Service doesn’t utilize the TLS protocol.
The Egendata solution uses the following encryption algorithm(s) from the SubtleCrypto interface
| Algorithm | Description |
|---|---|
| AES-128-CBC | For symmetric encryption |
| RSAES-OAEP | For asymmetric encryption (2048 bit key) |
The Egendata solution uses the following signature algorithm(s) from the SubtleCrypto interface
| Algorithm | Description |
|---|---|
| RSASSA-PSS (PS256) | For signing (2048 bit key) |
All encryption and signing in the phone app is done through msrcrypto which implements a shim of SubtleCrypto in pure JavaScript. Since this implementation is extremely slow, it will have to be replaced by a native implementation of the JOSE standard wrapped as a react-native package. The current candidate for iOS implementation JOSESwift does not support RSA PSS - only RSA PKCS#1. If this functionality cannot be added to JOSESwift – signing will have to be done through RS256 instead of PS256
The Signee Service publishes the required public key(s) for other parties to use when verifying the authenticity of the signee’s signature. The public key(s) are published on the Signee service’s domain at endpoint /jwks(although can be customized).
The public key(s) are represented as JWKS format.
The recipient of an incoming Egendata Message, performs a query to the supposed Signee Service’s /jwks endpoint in order to obtain the public key(s) required for verification of the signature and thereby ensuring that the suggested service is in fact the issuer and signee of the received JWE payload.
Through secure TLS connection the verifier can with high confidence trust that it is in contact with the correct signee service.
The signature verification procedure described in this section is not yet implemented in the Client library, see: GitHub Client.
All messages exchanged between Services, Operator & Applications are signed with the sender party’s own signing key and transmitted as JWT to the receiving party.
The Egendata solution utilizes the Panva JOSE framework (GitHub) in order to be compliant with the following RFCs:
| RFC | Description |
|---|---|
| JWK | JSON Web Key RFC7517, format for encryption keys. |
| JWE | JSON Web Encryption RFC7516, format för encrypted data. In Egendata solution only the “General JWE JSON Serialization Syntax” is used due to that being the only one supporting multiple recipients. The content is encrypted with “A128CBC-HS256”(link?) and the recipient keys with “RSA-OAP”. |
| JWS | JSON Web Signature RFC7515, format for signed data. All data is signed before being encrypted. This allows the validation of the data source. |
| JWT | JSON Web Token RFC7519, format for transmission of claims between all parts of the Egendata solution. |
There are possibilities to use the ASE-256-CBC for symmetric encryption.
There are no current plans to migrate to ECDSA for signing.
Eventually signing key rotation is expected to be implemented, so that each message can be validated against the public key announced by sending party. The exception is the App, which is not acting as a Webserver, and therefore can’t publically announce its own public key, instead the public key is included in the message.
There are potential optimizations to be done in the Panva JOSE library regarding the contruction and decryption the JWT’s JWE content, e.g. the extraction of the correct key from the recipient list and to reuse of the same encryption key(but always with unique IV).