Dear Ashish,
Thanks. So if my understanding is correct the vendor specific library file exposes the API for "hasp_update" to access the key identified by the contents of the .hvc, including R/W access. So if an attacker hacked the hasp_update binary to call a different API or call the same API differently, they might be able to perform unauthorized operations on the key? (Maybe this is not the case, please see below.)
We used to prevent such attacks to some extent by applying the envelope on top of the program with such R/W capability. But my question #1 then still remains - would we be able to run such envelope-protected hasp_update program on a machine without any key installed, just with the HASP Runtime?
I would understand that if all operations in v2c etc. were tamper-proof and the only way the APIs in the .so/.a can manipulate keys, there was no need for the envelope protection.
Thanks!
Thanks. So if my understanding is correct the vendor specific library file exposes the API for "hasp_update" to access the key identified by the contents of the .hvc, including R/W access. So if an attacker hacked the hasp_update binary to call a different API or call the same API differently, they might be able to perform unauthorized operations on the key? (Maybe this is not the case, please see below.)
We used to prevent such attacks to some extent by applying the envelope on top of the program with such R/W capability. But my question #1 then still remains - would we be able to run such envelope-protected hasp_update program on a machine without any key installed, just with the HASP Runtime?
I would understand that if all operations in v2c etc. were tamper-proof and the only way the APIs in the .so/.a can manipulate keys, there was no need for the envelope protection.
Thanks!