topic Quote:Arya Pourtabatabaie in Intel® Software Guard Extensions (Intel® SGX)

SGX tcrypto <----> IPP CP

AArya2 — Tue, 14 Feb 2017 15:59:13 GMT

I'm trying to develop a simple remote attestation service, and since the SGX SDK does not provide wrappers for that (which I can't see why given that the procedure is both standardized and difficult) I thought I might use IPP for it.

Now, the IPP crypto library gives you a lot of freedom, for example it lets you choose your elliptic curve, while SGX crypto does not.

So do I have to configure my IPP context in a particular way so that it can communicate with SGX crypto?

Hi, Arya.

Rodolfo_S_ — Tue, 14 Feb 2017 17:58:37 GMT

Hi, Arya.

The reason why Intel doesn't provide a wrapper for the SP side is because the server side is completely independent from Intel SGX (i.e.: it doesn't need any SGX capable HW to perform remote attestation of an enclave).

Concerning your question, you have to use the NIST P-256 curve in order to work with in Intel SGX, and you also need to keep in mind the endianness of several structures that are used in the Remote Attestation process, as described in the documentation below:

https://01.org/sites/default/files/documentation/intel_sgx_sdk_developer_reference_for_linux_os_pdf.pdf

https://software.intel.com/sites/default/files/managed/3d/c8/IAS_1_0_API_spec_1_1_Final.pdf

Hi,

Huorong_L_ — Fri, 17 Feb 2017 09:38:00 GMT

I have found where the problem is. It seems that the endian in SGX API is not matched with that in IPP CP.

Hi, I came with a problem: The public portion of key pair generated by IPP API "ippsECCPGenKeyPair" (configured with ippsECCPSetStd(IppECCPStd256r1, pCtx) failed to pass the check in SGX enclave (using SGX API sgx_ecc256_check_point). What is the right way to make IPP CP communicate with SGX crypto? Attached:

sgx_ec256_public_t spPub; IppsECCPState* pECP = newStd_256_ECP(); //generate SP ECCDH key pair IppsPRNGState* pRandGen = newPRNG(); // 'external' PRNG IppsBigNumState* pSPPrivate = newBN(8, 0); IppsECCPPointState* pSPPublic = newECP_256_Point(); CHECK_RESULT(ippStsNoErr, ippsECCPGenKeyPair(pSPPrivate, pSPPublic, pECP, ippsPRNGen, pRandGen)); //sp public IppsBigNumState* pSPPublicX = newBN(8, 0); IppsBigNumState* pSPPublicY = newBN(8, 0); CHECK_RESULT(ippStsNoErr, ippsECCPGetPoint(pSPPublicX, pSPPublicY, pSPPublic, pECP)); CHECK_RESULT(ippStsNoErr, ippsGetOctString_BN(spPub.gx, 32, pSPPublicX)); CHECK_RESULT(ippStsNoErr, ippsGetOctString_BN(spPub.gy, 32, pSPPublicY));

I have another strange

AArya2 — Fri, 17 Feb 2017 14:59:15 GMT

I have another strange problem:

1) The Diffie-Hellman secret that IPP derives is the inverse of the one that SGX does, which is very strange since Intel generally sticks to the same endianness (little endian).

2) When trying to produce sig(g^b || g^a), I have a more strange problem yet. The x coordinate of the computed signature matches the first portion of the precomputed signature, in the sense that is its inverse. However, the y coordinate seems to have no relation whatsoever to the second portion of the precomputed signature.

-----output sample for problem 1

computed dh secret = 32 bytes:
{
0xd7, 0xc8, 0x88, 0x55, 0x52, 0xa3, 0xdc, 0xfc,
0xd2, 0xa7, 0x4a, 0x57, 0x1, 0x66, 0x1f, 0x9c,
0x6d, 0x22, 0xb5, 0xcd, 0xbe, 0xe6, 0x3c, 0xbe,
0xf8, 0x18, 0x34, 0x39, 0xc9, 0x93, 0x75, 0x4c
}
expected dh shared secret = 32 bytes:
{
0x4c, 0x75, 0x93, 0xc9, 0x39, 0x34, 0x18, 0xf8,
0xbe, 0x3c, 0xe6, 0xbe, 0xcd, 0xb5, 0x22, 0x6d,
0x9c, 0x1f, 0x66, 0x1, 0x57, 0x4a, 0xa7, 0xd2,
0xfc, 0xdc, 0xa3, 0x52, 0x55, 0x88, 0xc8, 0xd7
}

-----output sample for problem 2

computed gbga sig.x = 32 bytes:
{
0x97, 0x9e, 0xb9, 0x5a, 0xdd, 0x14, 0x17, 0xf2,
0xfa, 0xad, 0xfa, 0xd7, 0x66, 0x73, 0xfd, 0x71,
0x57, 0xf4, 0xe9, 0x8d, 0xee, 0xaf, 0x42, 0x5e,
0xbb, 0x8a, 0x4c, 0xd4, 0x84, 0xdc, 0x83, 0x6a
}
computed gbga sig.y = 32 bytes:
{
0x19, 0xa0, 0x3, 0x8f, 0x36, 0x11, 0xdc, 0x49,
0x69, 0x88, 0x15, 0x30, 0x9, 0x44, 0x57, 0x48,
0x9a, 0x59, 0x0, 0xf0, 0xa, 0xae, 0x6c, 0xd5,
0x80, 0x4d, 0xd2, 0xd0, 0x2b, 0x0, 0x83, 0x3f
}
expected gbga sig = 64 bytes:
{
0x6a, 0x83, 0xdc, 0x84, 0xd4, 0x4c, 0x8a, 0xbb,
0x5e, 0x42, 0xaf, 0xee, 0x8d, 0xe9, 0xf4, 0x57,
0x71, 0xfd, 0x73, 0x66, 0xd7, 0xfa, 0xad, 0xfa,
0xf2, 0x17, 0x14, 0xdd, 0x5a, 0xb9, 0x9e, 0x97,
0x6, 0x10, 0x58, 0x61, 0xa5, 0xbf, 0x7d, 0x2e,
0xab, 0xcc, 0x1a, 0x3e, 0x4f, 0x44, 0x15, 0xe7,
0x91, 0xca, 0x64, 0x2b, 0x42, 0xb7, 0x53, 0xd9,
0x71, 0x37, 0xf1, 0x9b, 0x31, 0xb5, 0xa5, 0x6b
}

--------------

Code available upon request :p

(I didn't include it because I use wrapper functions I wrote, so wouldn't have been that informative. If necessary, I can "unwrap" it.)

Quote:Arya Pourtabatabaie

Huorong_L_ — Mon, 20 Feb 2017 05:12:32 GMT

Arya Pourtabatabaie wrote:

I have another strange problem:

1) The Diffie-Hellman secret that IPP derives is the inverse of the one that SGX does, which is very strange since Intel generally sticks to the same endianness (little endian).

2) When trying to produce sig(g^b || g^a), I have a more strange problem yet. The x coordinate of the computed signature matches the first portion of the precomputed signature, in the sense that is its inverse. However, the y coordinate seems to have no relation whatsoever to the second portion of the precomputed signature.

-----output sample for problem 1
computed dh secret = 32 bytes:
{
0xd7, 0xc8, 0x88, 0x55, 0x52, 0xa3, 0xdc, 0xfc,
0xd2, 0xa7, 0x4a, 0x57, 0x1, 0x66, 0x1f, 0x9c,
0x6d, 0x22, 0xb5, 0xcd, 0xbe, 0xe6, 0x3c, 0xbe,
0xf8, 0x18, 0x34, 0x39, 0xc9, 0x93, 0x75, 0x4c
}
expected dh shared secret = 32 bytes:
{
0x4c, 0x75, 0x93, 0xc9, 0x39, 0x34, 0x18, 0xf8,
0xbe, 0x3c, 0xe6, 0xbe, 0xcd, 0xb5, 0x22, 0x6d,
0x9c, 0x1f, 0x66, 0x1, 0x57, 0x4a, 0xa7, 0xd2,
0xfc, 0xdc, 0xa3, 0x52, 0x55, 0x88, 0xc8, 0xd7
}
-----output sample for problem 2
computed gbga sig.x = 32 bytes:
{
0x97, 0x9e, 0xb9, 0x5a, 0xdd, 0x14, 0x17, 0xf2,
0xfa, 0xad, 0xfa, 0xd7, 0x66, 0x73, 0xfd, 0x71,
0x57, 0xf4, 0xe9, 0x8d, 0xee, 0xaf, 0x42, 0x5e,
0xbb, 0x8a, 0x4c, 0xd4, 0x84, 0xdc, 0x83, 0x6a
}
computed gbga sig.y = 32 bytes:
{
0x19, 0xa0, 0x3, 0x8f, 0x36, 0x11, 0xdc, 0x49,
0x69, 0x88, 0x15, 0x30, 0x9, 0x44, 0x57, 0x48,
0x9a, 0x59, 0x0, 0xf0, 0xa, 0xae, 0x6c, 0xd5,
0x80, 0x4d, 0xd2, 0xd0, 0x2b, 0x0, 0x83, 0x3f
}
expected gbga sig = 64 bytes:
{
0x6a, 0x83, 0xdc, 0x84, 0xd4, 0x4c, 0x8a, 0xbb,
0x5e, 0x42, 0xaf, 0xee, 0x8d, 0xe9, 0xf4, 0x57,
0x71, 0xfd, 0x73, 0x66, 0xd7, 0xfa, 0xad, 0xfa,
0xf2, 0x17, 0x14, 0xdd, 0x5a, 0xb9, 0x9e, 0x97,
0x6, 0x10, 0x58, 0x61, 0xa5, 0xbf, 0x7d, 0x2e,
0xab, 0xcc, 0x1a, 0x3e, 0x4f, 0x44, 0x15, 0xe7,
0x91, 0xca, 0x64, 0x2b, 0x42, 0xb7, 0x53, 0xd9,
0x71, 0x37, 0xf1, 0x9b, 0x31, 0xb5, 0xa5, 0x6b
}
--------------

Code available upon request :p

(I didn't include it because I use wrapper functions I wrote, so wouldn't have been that informative. If necessary, I can "unwrap" it.)

The endian in SGX API is not matched with that in IPP CP. For example, the result from ippsGetOctString_BN is inverse to that from ippsGet_BN. You should pay attention to the byte order.