Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Use struct sm_cwa_session from sm.h in dnie #930
This is just a question not an issue. Making dnie dependent of the sm I realized that the structures that the dnie uses for establishing the secure channel are (more or less) already defined in sm.h file.
In cwa14890.h the dnie uses the following structures to handle the sm:
In sm.h there is another structure to establish the sm:
If you see, the sm structures defined in sm.h are the same than in cwa14890.h except for the sig buffer. This field is just te signature buffer used when creating the secure channel and it is transient (only used when the channel is created). I think we can get rid of this duplicate structures and I have implemented a quick PoC which is working with dnie, the commit is this one:
And anyone with a dnie can test it with this branch:
Besides I decided to finally delete the sc_reset at channel creation, in dnie 3.0 there are a lot of secure channels being created and I don't want to reset the card all the time. No problems so far with that branch in my testing.
That's all. Tell me if you think this is useful or I have to just forget it.
In my testing I have experienced the same issue but it is very, very rare (maybe a fail in one hundred, and usually only in the first tests). I don't know if it depends on the reader or what. Nevertheless I think it is important to remove that sc_reset, the idea has been around for a long time but I was reluctant because I supposed there was a reason for it to be there. But now I am more comfortable with the code and I don't know any reason to perform that reset (official implementation does not use it either).
So, my only question is if I continue with this idea of using the common sm structures and types inside the DNIe or I just remove the sc_reset and keep custom DNIe structs... Do you think using common sm structures is useful or just a crazy idea?
as said before, the dnie didn't use much of the SM framework created by @viktorTarasov. Instead everything was implemented at the driver level (again). So yes, unifying is a good way to go.
A step further down this road, the dnie driver should always use