ZtcLocalAgent AddCertificateHashEntry

[Brian_Earp]

I'm trying to use the function AddCertificateHashEntry (part of the PTHICommand class defined in PTHICommand.cpp). I pass in the right parameters, but I never get a response buffer from HECI. I realize the ZtcLocalAgent sample as written never calls this function, so could this be a SDK bug? Also, is this API function similar to the same named function defined in the network interface? If so, certain parts of the structure are missing from the command buffer (e.g. hashtypetype) and the ordering seems different.

Specifically, what happens is the command gets sent and bytesWritten is correct. Then, when I step through HECIWin::ReceiveMessage the ReadFile call gets a response of 1 but bytesRead is 0 for this command. It's is silently failing without any error code from the HECI. If I call ReadFile a second time by modifying the code, ReadFile returns 0 and GetLastError is 997, overlapped I/O in progress. Then GetOverlappedResult just hangs forever waiting for it.

So, I think the driver is writing a zero sized response to the command, since the first ReadFile works and returns immediately with no data. API bug?

Please advise.

[RBens2 · Accepted solution]

Quoting - Brian Earp

I'm trying to use the function AddCertificateHashEntry (part of the PTHICommand class defined in PTHICommand.cpp). I pass in the right parameters, but I never get a response buffer from HECI. I realize the ZtcLocalAgent sample as written never calls this function, so could this be a SDK bug? Also, is this API function similar to the same named function defined in the network interface? If so, certain parts of the structure are missing from the command buffer (e.g. hashtypetype) and the ordering seems different.

Specifically, what happens is the command gets sent and bytesWritten is correct. Then, when I step through HECIWin::ReceiveMessage the ReadFile call gets a response of 1 but bytesRead is 0 for this command. It's is silently failing without any error code from the HECI. If I call ReadFile a second time by modifying the code, ReadFile returns 0 and GetLastError is 997, overlapped I/O in progress. Then GetOverlappedResult just hangs forever waiting for it.

So, I think the driver is writing a zero sized response to the command, since the first ReadFile works and returns immediately with no data. API bug?

Please advise.

Hi Brian,

I don't think that you can do a call to add a cert hash before the system gets into a post-configuration state. The only way to add a cert hash to the system before the post-configuration state is to do it by hand in the MEBx. If you could programmatically add a cert hash before configuration, then malicious software could load up its own cert hash and get the system to configure with a rogue SCS. Therefore, the system will not let you programmatically add a cert hash before the system gets configured.

Regards,
Roger

[Brian_Earp]

Quoting - rogerb

Hi Brian,

I don't think that you can do a call to add a cert hash before the system gets into a post-configuration state. The only way to add a cert hash to the system before the post-configuration state is to do it by hand in the MEBx. If you could programmatically add a cert hash before configuration, then malicious software could load up its own cert hash and get the system to configure with a rogue SCS. Therefore, the system will not let you programmatically add a cert hash before the system gets configured.

Regards,
Roger

Thanks, that explains that. Let me ask then why Intel provides that API at all? Under what use case could it be used for?

[RBens2]

Quoting - Brian Earp

Thanks, that explains that. Let me ask then why Intel provides that API at all? Under what use case could it be used for?

The remote config hash isn't the only hash that the system deals with. Also, you can add a hash with the system in a configured state, and then do a partial unconfigure in which case the new hash will remain in the ME. You could possibly work out something with that.

[Brian_Earp]

Quoting - rogerb

The remote config hash isn't the only hash that the system deals with. Also, you can add a hash with the system in a configured state, and then do a partial unconfigure in which case the new hash will remain in the ME. You could possibly work out something with that.

Ok, thank you for the quick response. I don't think there's a way in the software using PTHI to put the system into small business mode, add the hash, then unprovision it. It looks like in order to use remote configuration without ever touching the system beyond plugging in power and network (and installing a local software agent) the administrator must purchase a real certificate.

I would like to make the suggestion that future versions of the AMT SDK documentation include vital information like this so developers know which functions are limited based on the current state of the system.

[RBens2]

Quoting - Brian Earp

Ok, thank you for the quick response. I don't think there's a way in the software using PTHI to put the system into small business mode, add the hash, then unprovision it. It looks like in order to use remote configuration without ever touching the system beyond plugging in power and network (and installing a local software agent) the administrator must purchase a real certificate.

I would like to make the suggestion that future versions of the AMT SDK documentation include vital information like this so developers know which functions are limited based on the current state of the system.

The ability of AMT to control and monitor the systems have made Intel so paranoid about security, that there are some things that you just can't do to the system remotely. The best solution to this is to get your OEM to pre-provision the systems before they get shipped to you. I know that some of the OEMs offer pre-provisioning as a service, but I don't know exactly which ones do, I do know that HP does, but I don't know about others.