A C implementation of elliptic-curve-based Direct Anonymous Attestation (DAA) signatures. Created to support the Xaptum Edge Network Fabric, an IoT Network Solution.
Home Page: https://www.xaptum.com
License: Apache License 2.0
Since the decision to split this project into libecdaa and libecdaa-tpm, it appears our .travis/run-cppcheck.sh script no longer works, because the directory structure of the generated files has changed.
Currently, most of the by-reference parameters in our functions, especially internal ones, are not const. Even when logically they definitely should be.
This is a bit of a sticky wicket, because AMCL's API doesn't use const, and many of those functions do have side-effects on their parameters, sometimes subtly so.
Further, taking our parameters as const then casting the const away can be dangerous, even when the source code appears to not modify the parameter, because the compiler may get too smart. For example, if the machine code from AMCL ends up doing something cute where the memory gets updated then changed back (allowed because the AMCL code took it as non-const), but that memory is actually ROM (because our code, which defined it, said it's const), we could fault.
The link to the Ubuntu repo (http://dl.bintray.com/xaptum/deb) is not public accessible.
Can you please provide link for the Ubuntu releases (deb https://xaptum.jfrog.io/ui/native/debian bionic main) in the README.md
Do you plan to provide packages and support for recent and future Debian/Ubuntu releases?
Best regards,
Michael Preisach
Currently, the ecdaa_prng struct is a wrapper around AMCL's csprng. However, because ecdaa_prng is part of our public API, this means a user of our API needs to have access to AMCL headers (ecdaa_prng is used basically everywhere, so it's inescapable).
It may not be possible to hide the AMCL dependence and also allow for no-malloc's. So, most likely we need to make sure we're being smart about how we set AMCL include paths, to ensure our user can include our API without having to know anything about AMCL, even if they install our library somewhere.
Set the ECDAA_LIB_DIR variables, etc. necessary for someone to use this as a library in their project by simply including this as a subdirectory and using find_package. Maybe also provide an example FindECDAA.cmake.
Currently, we're using AMCL's BIG and its associated modular functions for modular arithmetic. However, it looks like those functions are just using the classical algorithms (and, in fact, some of them have comments that explicitly say they're slow!).
AMCL also has finite-field types, which allow reduction modulo the field order. So maybe those are more efficient?
This isn't a pressing concern, even when we start trying to be more efficient, because modular arithmetic is not the processor hog (the curve stuff, especially the pairing computations) are the killers.
Functionality already exists within /examples, so we need to add an interface to use all tools from one place.
Commands:
This errata corrected the underlying TPM_Sign operation for ECDAA signatures, and should be what we use moving forward. Specifically, this TCG revision/errata is what is available on Infineon's FW7.63 chips
The valgrind memcheck tests in travis-ci are reporting multiple "defects" (e.g. uninitialized memory).
However, our travis setup is apparently incorrect, because these defects are not showing up as failures, and so the build continues to pass. This also means that the full valgrind output isn't being shown in the travis logs, so we don't know what is causing the issues.
We need to:
The latest AMCL adds #define byte uint8_t to arch.h, breaking files like tpm-test-utils.h that use byte as a variable name.
Currently, following FIDO's DAA definitions, we're not using a signature revocation capability in our signatures. However, for our uses, that would be required.
Perhaps, go back to Bernhard, et al, to alter the FIDO algorithm to allow linkability. Or, maybe we should just go ahead and start implementing Camenisch et al's proposed update to TPM2.0.
Must be thoughtful on how to update this, but still allow for interop with FIDO.
Right now, we statically set SH256 as the hash algorithm. To support different signature algorithms, and different pairing-friendly curves (i.e. different curve security levels would require different hash output lengths), we need to allow the hash algorithm to be set.
The CTests which use a key in a present TPM fail in different setups (Tests #13-16).
Generating a key inside the TPM with resulting pub_key.txt and handle.txt works with ecdaa-create_tpm_key-util
Given the a working TPM holding the correct key, the TPM tests pass.
libtss2 built from source and with libtss2-dev package from Debian/UbuntuGiven a minimal installation, I did the following on Debian 10:
apt install gcc cmake build-essential doxygen doxygen-latex parallel libtss2-dev
apt install git
git clone https://github.com/xaptum/ecdaa
mkdir ecdaa/build && cd ecdaa/build
export CMAKE_PREFIX_PATH=/usr
../.travis/install-amcl.sh
../.travis/install-amcl.sh ./amcl /usr FB256BN
../.travis/install-amcl.sh ./amcl /usr FP256BN
cmake .. -DCMAKE_BUILD_TYPE=Release -DECDAA_CURVES=FP256BN -DCMAKE_INSTALL_PREFIX=/usr -DECDAA_TPM_SUPPORT=ON -DBUILD_EXAMPLES=ON -DBUILD_BENCHMARKS=ON
cmake --build . --target install
testBin/ecdaa-create_tpm_key-util test/tpm/pub_key.txt test/tpm/handle.txt
ctest -V
Instead of using libtss2-dev you provide an install script which builds libtss2 from source. I tried that as well.
UpdateCTestConfiguration from :/root/ecdaa/build/DartConfiguration.tcl
Parse Config file:/root/ecdaa/build/DartConfiguration.tcl
UpdateCTestConfiguration from :/root/ecdaa/build/DartConfiguration.tcl
Parse Config file:/root/ecdaa/build/DartConfiguration.tcl
Test project /root/ecdaa/build
Constructing a list of tests
Done constructing a list of tests
Updating test list for fixtures
Added 0 tests to meet fixture requirements
Checking test dependency graph...
Checking test dependency graph end
test 1
Start 1: ecdaa-big_256_56-tests
1: Test command: /root/ecdaa/build/testBin/ecdaa-big_256_56-tests
1: Test timeout computed to be: 1500
1: Starting mpi_utils::hash_not_zero...
1: success!
1: Starting mpi_utils::hash_two_not_zero...
1: success!
1: Starting mpi_utils::hash_two_same_messages...
1: success!
1: Starting mpi_utils::hash_ok_with_no_msg...
1: success!
1: Starting mpi_utils::hash_same_message...
1: success!
1: Starting mpi_utils::mul_and_add_all_zeros...
1: success
1: Starting mpi_utils::mul_and_add_all_ones...
1: success
1: Starting mpi_utils::mul_and_add_modulus_two...
1: success
1: Starting mpi_utils::mul_and_add_normalization_works...
1: success
1: Starting mpi_utils::mul_and_add_greater_than_modulus_ok...
1: success
1: Starting mpi_utils::mul_and_add_small_sanity_check...
1: success
1/16 Test #1: ecdaa-big_256_56-tests ................. Passed 0.00 sec
test 2
Start 2: ecdaa-credential_FP256BN-tests
2: Test command: /root/ecdaa/build/testBin/ecdaa-credential_FP256BN-tests
2: Test timeout computed to be: 1500
2: Starting credential::cred_generate_validate...
2: success
2: Starting credential::lengths_same...
2: success
2: Starting credential::cred_generate_then_serialize_deserialize...
2: success
2: Starting credential::cred_generate_then_serialize_deserialize_file...
2: success
2: Starting credential::cred_generate_then_serialize_deserialize_fp...
2: success
2/16 Test #2: ecdaa-credential_FP256BN-tests ......... Passed 0.08 sec
test 3
Start 3: ecdaa-ecp2_FP256BN-tests
3: Test command: /root/ecdaa/build/testBin/ecdaa-ecp2_FP256BN-tests
3: Test timeout computed to be: 1500
3: Starting ecp2_FP256BN::g2_basepoint_not_inf...
3: success
3: Starting ecp2_FP256BN::g2_serialize_then_deserialize_basepoint...
3: success
3: Starting ecp2_FP256BN::g2_lengths_same...
3: success
3: Starting ecp2_FP256BN::g2_deserialize_badformat_fails...
3: success
3: Starting ecp2_FP256BN::g2_deserialize_badcoords_fails...
3: success
3/16 Test #3: ecdaa-ecp2_FP256BN-tests ............... Passed 0.00 sec
test 4
Start 4: ecdaa-ecp_FP256BN-tests
4: Test command: /root/ecdaa/build/testBin/ecdaa-ecp_FP256BN-tests
4: Test timeout computed to be: 1500
4: Starting ecp_FP256BN::g1_basepoint_not_inf...
4: success
4: Starting ecp_FP256BN::g1_serialize_then_deserialize_basepoint...
4: success
4: Starting ecp_FP256BN::g1_lengths_same...
4: success
4: Starting ecp_FP256BN::g1_deserialize_badformat_fails...
4: success
4: Starting ecp_FP256BN::g1_deserialize_badcoords_fails...
4: success
4: Starting pairing_curve_utils::random_num_mod_order_is_valid...
4: success
4/16 Test #4: ecdaa-ecp_FP256BN-tests ................ Passed 2.08 sec
test 5
Start 5: ecdaa-group_public_key_FP256BN-tests
5: Test command: /root/ecdaa/build/testBin/ecdaa-group_public_key_FP256BN-tests
5: Test timeout computed to be: 1500
5: Starting group_public_key::serialize_then_deserialize_basepoints...
5: success
5: Starting group_public_key::serialize_then_deserialize_basepoints_file...
5: success
5: Starting group_public_key::serialize_then_deserialize_basepoints_fp...
5: success
5: Starting group_public_key::lengths_same...
5: success
5: Starting group_public_key::deserialize_garbage_fails...
5: success
5/16 Test #5: ecdaa-group_public_key_FP256BN-tests ... Passed 0.01 sec
test 6
Start 6: ecdaa-issuer_keypair_FP256BN-tests
6: Test command: /root/ecdaa/build/testBin/ecdaa-issuer_keypair_FP256BN-tests
6: Test timeout computed to be: 1500
6: Starting issuer_keypair::issuer_secrets_are_valid...
6: success
6: Starting issuer_keypair::generated_validates...
6: success
6: Starting issuer_keypair::lengths_same...
6: success
6: Starting issuer_keypair::generate_then_serialize_deserialize...
6: success
6: Starting issuer_keypair::generate_then_serialize_deserialize_file...
6: success
6: Starting issuer_keypair::generate_then_serialize_deserialize_fp...
6: success
6/16 Test #6: ecdaa-issuer_keypair_FP256BN-tests ..... Passed 0.05 sec
test 7
Start 7: ecdaa-member_keypair_FP256BN-tests
7: Test command: /root/ecdaa/build/testBin/ecdaa-member_keypair_FP256BN-tests
7: Test timeout computed to be: 1500
7: Starting member_keypair::member_secret_is_valid...
7: success
7: Starting member_keypair::member_public_is_valid...
7: success
7: Starting member_keypair::zero_nonce_ok...
7: success
7: Starting member_keypair::lengths_same...
7: success
7: Starting member_keypair::generated_validates...
7: success
7: Starting member_keypair::serialize_deserialize_secret...
7: success
7: Starting member_keypair::serialize_deserialize_public_no_check...
7: success
7: Starting member_keypair::serialize_deserialize_public_no_check...
7: success
7: Starting member_keypair::serialize_deserialize_secret_file...
7: success
7: Starting member_keypair::serialize_deserialize_public_no_check_file...
7: success
7: Starting member_keypair::serialize_deserialize_public_no_check_file...
7: success
7: Starting member_keypair::serialize_deserialize_secret_fp...
7: success
7: Starting member_keypair::serialize_deserialize_public_no_check_fp...
7: success
7: Starting member_keypair::serialize_deserialize_public_no_check_fp...
7: success
7/16 Test #7: ecdaa-member_keypair_FP256BN-tests ..... Passed 0.02 sec
test 8
Start 8: ecdaa-schnorr_FP256BN-tests
8: Test command: /root/ecdaa/build/testBin/ecdaa-schnorr_FP256BN-tests
8: Test timeout computed to be: 1500
8: Starting schnorr::schnorr_keygen_sane...
8: success
8: Starting schnorr::schnorr_sign_sane...
8: success
8: Starting schnorr::schnorr_verify_wrong_key...
8: success
8: Starting schnorr::schnorr_verify_wrong_msg...
8: success
8: Starting schnorr::schnorr_verify_bad_sig...
8: success
8: Starting schnorr::schnorr_sign_integration...
8: success
8: Starting schnorr::schnorr_sign_integration_other_points...
8: success
8: Starting schnorr::schnorr_basename...
8: success
8: Starting schnorr::schnorr_wrong_basename_fails...
8: success
8: Starting schnorr::schnorr_credential_sign_sane...
8: success
8: Starting schnorr::schnorr_credential_sign_integration...
8: success
8: Starting schnorr::schnorr_issuer_sign_sane...
8: success
8: Starting schnorr::schnorr_issuer_sign_integration...
8: success
8/16 Test #8: ecdaa-schnorr_FP256BN-tests ............ Passed 0.04 sec
test 9
Start 9: ecdaa-signature_FP256BN-tests
9: Test command: /root/ecdaa/build/testBin/ecdaa-signature_FP256BN-tests
9: Test timeout computed to be: 1500
9: Starting signature::sign_then_verify_good...
9: success
9: Starting signature::sign_then_verify_on_rev_list...
9: success
9: Starting signature::sign_then_verify_bad_basename_fails...
9: success
9: Starting signature::sign_then_verify_no_basename...
9: success
9: Starting signature::sign_then_verify_on_bsn_rev_list...
9: success
9: Starting signature::sign_then_verify_unlinkable...
9: success
9: Starting signature::lengths_same...
9: success
9: Starting signature::serialize_deserialize...
9: success
9: Starting signature::serialize_deserialize_file...
9: success
9: Starting signature::serialize_deserialize_fp...
9: success
9: Starting signature::pseudonym...
9: success
9: Starting signature::serialize_deserialize...
9: success
9/16 Test #9: ecdaa-signature_FP256BN-tests .......... Passed 0.26 sec
test 10
Start 10: ecdaa-schnorr_FP256BN-fuzz
10: Test command: /root/ecdaa/build/testBin/ecdaa-schnorr_FP256BN-fuzz
10: Test timeout computed to be: 1500
10: Starting schnorr::schnorr_repeated...
10: success
10/16 Test #10: ecdaa-schnorr_FP256BN-fuzz ............. Passed 0.08 sec
test 11
Start 11: ecdaa-integration-tests
11: Test command: /usr/bin/python "/root/ecdaa/build/testBin//ecdaa-integration-tests.py" "/root/ecdaa/build/bin/"
11: Test timeout computed to be: 1500
11: Group successfully created!
11: Group public key successfully saved!
11: Member key-pair successfully created!
11: Credential successfully created!
11: Credential validated!
11: Signature successfully created!
11: Signature successfully verified!
11: Group successfully created!
11: Group public key successfully saved!
11: Member key-pair successfully created!
11: Credential successfully created!
11: Credential validated!
11: Group public key successfully saved!
11: Member key-pair successfully created!
11: Credential successfully created!
11: Credential validated!
11: Group public key successfully saved!
11: Member key-pair successfully created!
11: Credential successfully created!
11: Credential validated!
11: Signature successfully created!
11: Signature not valid!
11: Signature successfully created!
11: Signature not valid!
11: Signature successfully created!
11: Signature successfully verified!
11: Group successfully created!
11: Group successfully created!
11: Group public key successfully saved!
11: Member key-pair successfully created!
11: Credential successfully created!
11: Credential validated!
11: Group public key successfully saved!
11: Member key-pair successfully created!
11: Credential successfully created!
11: Credential validated!
11: Signature successfully created!
11: Signature not valid!
11/16 Test #11: ecdaa-integration-tests ................ Passed 0.35 sec
test 12
Start 12: tool_test
12: Test command: /root/ecdaa/test/tool-test.sh "/root/ecdaa/build/tool"
12: Test timeout computed to be: 1500
12: Generating issuer keys...
12: ok
12: Generating member keys...
12: ok
12: Extracting issuer's group public key...
12: ok
12: Create a credential, and credential signature, on the member's public key...
12: ok
12: Validate a credential issued for the given member public key...
12: ok
12: Create a DAA signature over the message...
12: ok
12: Verify the signature...
12: ok
12: Check that signature does NOT verify for a revoked secret key...
12: Signature doesn't verify
12: Check that signature does NOT verify for a different message...
12: Signature doesn't verify
12/16 Test #12: tool_test .............................. Passed 0.09 sec
test 13
Start 13: ecdaa-schnorr_TPM_FP256BN-tests
13: Test command: /root/ecdaa/build/testBin/ecdaa-schnorr_TPM_FP256BN-tests
13: Test timeout computed to be: 1500
13: Starting tpm-test::full_test...
13: Error in schnorr_verify_TPM_FP256BN, ret=-1, tpm_rc=0x0
13: Condition '0==1' failed
13: in file: '/root/ecdaa/build/test/tpm/schnorr_TPM_FP256BN-tests.c'
13: in function: 'full_test'
13: at line: 76
13: exiting
13/16 Test #13: ecdaa-schnorr_TPM_FP256BN-tests ........***Failed 0.22 sec
test 14
Start 14: ecdaa-signature_TPM_FP256BN-tests
14: Test command: /root/ecdaa/build/testBin/ecdaa-signature_TPM_FP256BN-tests
14: Test timeout computed to be: 1500
14: Starting signature_TPM_FP256BN::sign_then_verify_good...
14: Condition '0 == ecdaa_signature_FP256BN_verify(&sig, &fixture.ipk.gpk, &fixture.revocations, fixture.msg, fixture.msg_len, fixture.basename, fixture.basename_len)' failed
14: in file: '/root/ecdaa/build/test/tpm/signature_TPM_FP256BN-tests.c'
14: in function: 'sign_then_verify_good'
14: at line: 117
14: exiting
14/16 Test #14: ecdaa-signature_TPM_FP256BN-tests ......***Failed 0.67 sec
test 15
Start 15: ecdaa-tpm_FP256BN-test
15: Test command: /root/ecdaa/build/testBin/ecdaa-tpm_FP256BN-test
15: Test timeout computed to be: 1500
15: Called TPM2_Commit with empty buffers, now count=8, and
15: E:{0X4, 0XC7, 0XEC, 0X21, 0X47, 0X79, 0X4D, 0X9D, 0XF1, 0X9B, 0X86, 0X13, 0XE6, 0X1D, 0XB5, 0XC7, 0X95, 0X77, 0X2C, 0X4D, 0XEC, 0X38, 0XEC, 0X1A, 0XCF, 0XD8, 0X69, 0X7, 0X64, 0XDE, 0XE0, 0XA1, 0XE0, 0X8F, 0XD2, 0XB2, 0XE4, 0X10, 0X66, 0XD4, 0X69, 0X82, 0X39, 0X6D, 0X9F, 0X34, 0XA, 0X18, 0X22, 0X2, 0X8B, 0XE7, 0X74, 0XA8, 0XE6, 0X80, 0X92, 0X95, 0X53, 0X7D, 0X6A, 0XF7, 0XF9, 0XA, 0X43, }
15:
15: [s]G1 - c*pub_key={0X4, 0XD0, 0X2E, 0X4F, 0X78, 0X72, 0XF6, 0X2A, 0X24, 0X43, 0XD5, 0XB6, 0X68, 0X5A, 0X2F, 0X9E, 0XCD, 0XA8, 0X9E, 0X6C, 0XE3, 0X96, 0X6C, 0X8A, 0X94, 0X33, 0X79, 0XA2, 0XE5, 0X91, 0X13, 0XA6, 0XF5, 0XF0, 0X66, 0X5D, 0XB, 0XF1, 0X89, 0XD3, 0X43, 0X58, 0XDF, 0X3B, 0X4B, 0X3F, 0XDB, 0XB3, 0X18, 0X91, 0X39, 0XE9, 0XCA, 0XB3, 0XA0, 0XFA, 0XAB, 0X49, 0XE8, 0X6A, 0X77, 0X4, 0XF6, 0XF9, 0X78, }
15:
15: Error: [s]G1 - T*pub_key != E
15: Condition '0 == 1' failed
15: in file: '/root/ecdaa/build/test/tpm/tpm_FP256BN-test.c'
15: in function: 'signature_math_checks'
15: at line: 110
15: exiting
15/16 Test #15: ecdaa-tpm_FP256BN-test .................***Failed 0.21 sec
test 16
Start 16: ecdaa-schnorr_TPM_FP256BN-fuzz
16: Test command: /root/ecdaa/build/testBin/ecdaa-schnorr_TPM_FP256BN-fuzz
16: Test timeout computed to be: 1500
16: Starting schnorr_TPM::schnorr_TPM_repeated...
16: Error in schnorr_verify_TPM_FP256BN, ret=-1, tpm_rc=0x0
16: Condition '0==1' failed
16: in file: '/root/ecdaa/build/test/tpm/schnorr_TPM_FP256BN-fuzz.c'
16: in function: 'schnorr_TPM_repeated'
16: at line: 92
16: exiting
16/16 Test #16: ecdaa-schnorr_TPM_FP256BN-fuzz .........***Failed 0.42 sec
75% tests passed, 4 tests failed out of 16
Total Test time (real) = 4.58 sec
The following tests FAILED:
13 - ecdaa-schnorr_TPM_FP256BN-tests (Failed)
14 - ecdaa-signature_TPM_FP256BN-tests (Failed)
15 - ecdaa-tpm_FP256BN-test (Failed)
16 - ecdaa-schnorr_TPM_FP256BN-fuzz (Failed)
Errors while running CTest
I cannot get these test to pass. It seems to be a problem with the file format of pub_key.txt
When playing around with the provided functions to parse the public key I ended up with the error message that the pubkey does not lie on the ECC curve (probably a file encoding problem?).
Best regards,
Michael Preisach
Every once in a while, a travis build will fail, but then succeed when re-run. The error is that prng_init fails.
Most likely, the sufficient-entropy check in the init function is failing on the travis VMs.
[ 91%] Building C object CMakeFiles/ecdaa.dir/src/signature_TPM.c.o
/usr/local/Homebrew/Library/Homebrew/shims/super/clang -Decdaa_EXPORTS -I/tmp/ecdaa-20180406-57779-n5hp1d/ecdaa-0.8.3/build/include -isystem /usr/local/include -DDISABLE_LIBSODIUM_RNG_SEED_FUNCTION -Werror -Wall -Wextra -std=c99 -Wno-missing-field-initializers -DNDEBUG -fPIC -o CMakeFiles/ecdaa.dir/src/signature_TPM.c.o -c /tmp/ecdaa-20180406-57779-n5hp1d/ecdaa-0.8.3/build/src/signature_TPM.c
/tmp/ecdaa-20180406-57779-n5hp1d/ecdaa-0.8.3/build/src/prng.c:108:16: error: use of undeclared identifier 'INT_MAX'
} else if (INT_MAX < seed_size) {
^
1 error generated.
AMCL's randomnum function generates a random number and then reduces it modulo the group order. If the maximum value of a BIG (AMCL's mpi type) isn't a multiple of the group order, this might cause biased random numbers.
I say "might", because the AMCL code has a comment right before modular reduction in the randomnum code that says: "/* reduce modulo a BIG. Removes bias */". I'm just not yet sure if that saves us.
If we need to, we can of course pull the classic move of only taking random numbers from the rng if they fit in a window that is a multiple of the group order (this is what libsodium's randombytes_uniform does:
/* upper_bound is the group order */
uint32_t min = (1U + ~upper_bound) % upper_bound; /* = 2**32 mod upper_bound */
do {
r = randombytes_random();
} while (r < min);
/* r is now clamped to a set whose size mod upper_bound == 0
* the worst case (2**31+1) requires ~ 2 attempts */
return r % upper_bound;We should adapt this PR and this PR in xaptum-tpm, to make sure we're testing the building of static libs and installation in travis.
Using a property-based testing framework like github.com/silentbicycle/theft would be nice.
But, baseline, we need to hit more of our code with simple tests, particularly the serialization stuff.
The version in CMakeLists.txt was not bumped from 0.10.1 when the v0.10.2 release was cut. My suggestion is to bump to v0.10.3 and release again as v0.10.3.
After adapting libsodium's randombytes_buf (cf. #9), use this to always seed an rng.
To support the unlinkability feature of ECDAA, signing a message should be possible without adding a basename to it.
This shortens the resulting signature and is already supported by ecdaa_signature_ZZZ_serialize and ecdaa_signature_ZZZ_deserialize.
When I use ecdaa_signature_ZZZ_sign with a valid basename, it succeeds.
By providing an empty basename (basename length = 0), the function fails and the signature is not valid afterwards.
Tested with FP256BN.
When i try to execute schnorr_TPM-test, signature_TPM-test and tpm-test (while all the other executables run successfully), i get the following error:
Starting tpm-test::full_test...
Error: error reading in public key files 'pub_key.txt' and 'handle.txt'
Condition '0 == tpm_initialize(&ctx)' failed
I've noticed that these files do not exist on my build/test/ directory.
Could this be related to IBM's emulator or are we supposed to create those files ourselves?
If yes, are all the other executables using a different public key?
Thanks a lot!
Replace calls to schnorr_sign, etc with the appropriate calls into a TPM2.0 (i.e. TPM_SIGN, etc.), and allow users to choose software vs. TPM versions at runtime.
In AMCL's ate pairing code, it looks like the pairing doesn't work correctly if the given points aren't in affine form.
Why is this a requirement?
Mike Scott would be a good person to ask about this.
It's very important to check that a curve point that was received externally is a member of the expected group.
So, we need to make sure we're doing these checks in all the places where we should. Also, we need to audit our code for membership checking (currently, it's just a copy-paste of AMCL's code).
Relatedly, is there a good way of structuring the API so we ensure these checks are always made.
To limit the number of times someone access with basename mode DAA, we have to limit the number of times someone can join.
(Because someone who has many credentials, can generate many different nym with the same basename.)
So could you tell me how to limit the number of times someone can join, with this ecdaa library?
Explore self-hosting libsodium, the way we do for the TPM simulator
Running the simulator here shouldn't require xaptum-tpm to be built locally or installed locally. That's a confusing coupling for anyone wanting to run the full CI test suite locally.
I think it'd be better to just copy the simulator installation and running scripts into this repo too.
To clearly indicate what code is TPM-specific (and whether a final ecdaa library does or doesn't have TPM support), we should separate those two pieces into two modules, that create two separate libraries.
Add example programs that, e.g., run the join process, sign, and verify.
These should be production-ready.
I got errors from the compiler saying that the AMCL include files could not be found.
I built and installed the AMCL, but there were no amcl/big_256_28.h files anywhere on my system... but they were under amcl/include/big_256_28.h.
There were a number of files like that -- all under /opt/amcl/include
To get it to compile, I changed all of the source files to add the /include path.
I also had to add an include directory in the CMakeLists.txt file.
I'm not certain that I did the correct thing, but it seemed to work.
I checked it in under fej/rpi-compile
I had similar issues when compiling under a clean debian VM.
The publication ia.cr/2017/639 is the most-up-to-date work on the DAA signature algorithm. The authors of this paper work closely with the TCG on specifications and with TPM manufacturers, so the changes the propose often (though not always) find their way into changes on the TPM. We can use this most-up-to-date algorithm with current TPMs, but if all the changes proposed in that paper are eventually accepted by the TCG, updating to support that new TPM spec will be easy (simply removing steps that we perform, in order to allow the TPM to do them). And software-vs-TPM signatures can be created/verified transparently (as their can now, as well).
Further, our current implementation is a bit of a hybrid of previous definitions, due to our chasing changing TPM specification. By updating to this particular algorithm, we will have a more solid description of which algorithm we're implementing (it also has a security proof).
Lastly, this algorithm is the one used by the most-recent FIDO spec. So, if we transition, that will put us into interop with them (though, their reference implementation hasn't been updated to reflect this most-recent spec).
The differences appear to be in the issuing process (the Camenisch-Lysyanskaya signature on the credential is a little different), and looks like it should be straightforward to implement.
Currently, we obtain a random seed from a call to libsodium's randombytes_buf, or allow the user to supply the random seed, then use that to seed a userspace csprng which is then used for all subsequent randomness.
It may be wise to eschew the userspace csprng and just take randomness from some user-specified system source (e.g. getrandom or arc4random or just reading from /dev/urandom).
This is currently a commonly-recommended practice from many crypto experts (eg. DJB on urandom.
Some of the perils of using a userspace csprng include (to my knowledge):
Libsodium's randombytes_buf handles all that for us, but we just use it for seeding. We could just use randombytes_buf, but we also want to support platforms that may not be supported by libsodium.
So, maybe just be totally agnostic to this decision, and allow the user to specify this (and indicate that the common best answer will be, on recent-enough Linux, to use getrandom). That's putting a lot of power in the hands of the user, but may be the best way forward.
The tools/verify_ZZZ.c file hardcodes the usage of ACML functions and types with the BIG_256_56 prefix. However, that prefix is only valid on 64 bit architectures. On 32 bit, the correct prefix is BIG_256_28.
I just won't build the tools for the router card, right now. They aren't needed there.
Possibly related, hardcoding the 256 seems suspicious as well. Is that correct for all the curves that ECDAA supports (like BLS383)?
This is required for wrapping in Python, and some users may prefer to use a dynamic lib.
For our CMakeLists, should be easy. We'll probably have to figure out how to string-replace in the AMCL config python script, though (to make sure to include fPIC).
I tried to create the required signing key with create_tpm_key-util.c. The Error occurs when trying to clear the TPM:
# ./create_tpm_key pubkey.txt pubkeyhandle.txt
Saving public key to pubkey.txt and handle to pubkeyhandle.txt
WARNING:tcti:src/tss2-tcti/tcti-device.c:314:tcti_device_receive() TPM2 response size disagrees with number of bytes read from fd 3. Header says 0 but we read 29 bytes.
ERROR:sys:src/tss2-sys/api/Tss2_Sys_Execute.c:117:Tss2_Sys_ExecuteFinish() Malformed reponse: Invalid tag in response header: 0
Clear ret=0X80011
Condition 'TSS2_RC_SUCCESS == ret' failed
in file: '/root/ecdaa-network-wrapper/create_tpm_key-util.c'
in function: 'create_key'
at line: 154
When I comment out line 154-156 in create_tpm_key-util.c and manually clear the TPM in advance, another problem occurs while creating the primary key:
# ./create_tpm_key pubkey.txt pubkeyhandle.txt
Saving public key to pubkey.txt and handle to pubkeyhandle.txt
CreatePrimary ret=0X80012
Condition 'TSS2_RC_SUCCESS == ret' failed
in file: '/root/ecdaa-network-wrapper/create_tpm_key-util.c'
in function: 'create_key'
at line: 158
The Setup for tpm_tools and tpm_sapi is working properly.
My Setup is as follows:
If you need further Information about my Setup, feel free to contact me.
Verification is currently the slowest part of the LRSW-DAA algorithm. As mentioned in Chen, et al (doi: 10.1007/978-3-642-12510-2_16) this can be sped up using batch verification.
AMCL supports this (it's why the Miller Loop and the exponentiation are split in their implementation). In fact, the test of the pairing in their code includes a batch multiplication.
Chen, et all claim this resulted in a 40% speedup of the verification.
The current implementation of explicit_bzero is pretty dumb-headed, and its performance could probably be improved on systems supporting memset_s or explicit_bzero, etc. Libsodium's implementation of safe clearing does this well.
Similarly, libsodium's code for reading cryptographically-secure random bytes (randombytes_buf) is nice and very cross-platform.
So, since libsodium is ISC-licensed, adapt their code for our use.
Their randombytes_buf is probably more-general and more-cross-platform than we need.
Comments in AMCL's build setup indicate that some curve point multiplication algorithm(s) they use is/maybe patented.
I don't think we're using that, but make sure we're not.
The travis build of Coverity scan is currently failing (silently...).
It looks like this has been happening since we moved to out-of-tree builds in travis (which was a while ago). The issue is that the build commands given to Coverity can't use cd or pushd.
Maybe build as usual, then manually upload the results?
Currently, we only support BN254. AMCL supports two other curves, and its namespacing allows using different functions for different curves.
Our most pressing concern is to support the 256-bit Barreto-Naehrig curve implemented in TPM2.0 and used by FIDO (so we can test against their implementation).
AMCL supports defining other curves, so let's add that 256-bit BN TPM curve.
The easiest path would be to adopt AMCL's convention, and use namespacing to distinguish our functions that use different curves (e.g. ecdaa_signature_BN256TPM_sign).
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.