Clarify security-related limitation

[MikiDi]

Hi there!

Thanks for going through all this effort (to support some proprietary solution that doesn't support linux but is sometimes the only solution provided 😞 ).

Although I have an understanding of basic security principles, I feel like I don't fully grasp what the possible implications of following paragraph in the readme might be when I use this tool with a party that I otherwise trust.

There is also one security feature which is not implemented, because the algorithm is unknown. Whether this security through obscurity feature is really improving the security or not is debatable, but you should be aware that your personal data may be sent to anyone on the internet when using this application.

For the non-implemented feature, could you add some reference (to the relevant part in the implementation maybe) as to provide some context on where this is situated?
As to the "sent to anyone on the internet": what does this mean exactly? I understand that if you use this tool on a domain you don't trust, or if some payload sent contains sensitive info and is unencrypted that one could say "to anyone on the internet". Otherwise not so much 🤔 Could you please clarify?

Thanks again!

Michaël

[roelderickx]

Hello Michaël,

The remote site is sending messages to the Connective plugin to obtain the data from the id-card. In every message there is an activationToken tag containing a 2048 bit binary value, which must be verified to be valid by the plugin. In case the token is invalid the plugin is supposed to answer 'Activation required' without taking further action. The idea behind this is to assure the request comes from a trustworthy origin - someone who knows how to generate a valid token.

Neither an attacker nor someone writing an unofficial plugin is supposed to be able to generate a valid token. So we have to accept any activation token and assume it is valid, as can be seen in the function verify_activation_token on line 712 of connective-backend.py.

We do know something about the token though:

• A token is valid for 24 hours and expires around 6pm if I recall correctly
• A length of 2048 bit is not impossible for a checksum but rather unusual. The token could then be the concatenation of several checksums or an encrypted version of a known string. This string definitely contains the date in some form, given the first observation.

The whole security relies on the obscurity of the the string to encrypt and the encryption or hashing algorithm to be used. I personally do not believe in this kind of security, the technique to crack it is usually extremely easy and this example is no exception. However, since cracking is illegal I will not do that nor give you any clue on how to do it. It won't help us either, Connective will be forced to release an update with a different algorithm or require their customers to use the newer and more secure Connective SignID.

I believe the risk is really limited. Most people use the official plugin so the pool of potential victims is rather limited and anyone should take care not to use id-cards on shady websites. Encryption of the transmitted data is taken care of by the https protocol, an attacker who is able to impersonate and do a successful man-in-the-middle attack will be able to read anyone's data, regardless whether the official or the unofficial plugin is used.

[MikiDi]

Very clear :-) Thanks! I conclude that

your personal data may be sent to anyone on the internet when using this application

should be seen more as a disclaimer rather than anything very realistic in case of responsible use.