Feature request: TR-34 support

[kplese]

Can you please add support for TR-34 also?

[knovichikhin]

I'm curious why do you need TR-34 software support? Where most of this is very sensitive and needs to be done in hardware with secure certificate storage (on both sides).

Anyways, realistically it will be very hard for me to find time to do this. Last and the only time I implemented support for TR-34 it was "you'd have to pay me to do this again" kind of pain.

I'm also not sure if every KRD is going to have its own quirks because they have their own interpretation of TR-34. Or if TR-34 is not authoritative enough leaving things to individual implementations.

Anyways, if someone wants to contribute, they are welcome. It's just a series of steps between KRD and KDH.

[5n00py]

I just saw this conversation now. I worked on a KDH implementation in C for an HSM about a year ago. As for testing, I also attempted to develop a general framework in Python as part of this library. This remained unfinished, but can still be found as "work-in-progress" here: https://github.com/5n00py/psec/blob/feature/tr34/psec/tr34.py

As mentioned above, "every KRD is going to have its own quirks" and has its own "interpretation of TR-34", which makes it extreamly difficult to provide a general framework and you will end up implementing specific use cases. Thats also why I left the project above unfinished, as the C code went into production directly after end to end testing with the specific KRDs.

Regarding the Python implementation, the KeyBlockHeader part should be working and was designed to be compatible for both sides and to accommodate different interpretations of the standard. However, I used the asn1crypto library for CMS, which had some bugs, particularly in building enveloped data and I am not sure they are fixed by now. Also some provided test vectors seemed to be wrong (specially having too short IVs for the AES parts, as far as I remember).

Given these experiences, I am not entirely sure how much my contribution will help. Nevertheless, if anyone is interested in building up on that state, feel free to do so. However, I agree with the sentiment that TR-34 implementations can be quite challenging, and direct cooperation with hardware aspects and secure certificate storage can be crucial, besides having a secure RSA-OAEP implementation in the field.

[5n00py]

As an update here: I have made some chores on the TR-34 implementation that is part of my local fork. The current state can be found here: https://github.com/5n00py/psec/tree/feature/tr34

This includes mainly the core TR-34 functionality necessary to build the Header and KeyBlock and encrypt the transport key in the KB using an ephemeral key. In addition, it also includes some "helper" modules like some padding and file loading functionalities.

I think the so far provided could serve as a starting point in testing against HSM implementations from the KDH side, considering that the rest of TR-34 more or less aligns with the straightforward implementation of CMS and mainly the KeyBlock part stands out from this.

The proper doctests are still missing in the TR-34 module (I am still thinking about of what would be the most appropriate approach here), but the existing pystests should already cover all cases. Also the github actions checks on the server are currently failing, however, it seems they derive from a misconfiguration, potentially linked to recent server-side migrations or updates. I will still look into this...

But before I invest some more real work here, I would appreciate feedback on whether the approach taken in my fork is suitable for the library. I am also open to any inputs or suggestions as a form of "pre-review", understanding that the review process might take some time. If necessary, I could also refine and split up the commits to faciliate a smoother integration...