The libmicrofido2 from all-your-locks-are-belong-to-us

libmicrofido2's Issues

Implement authenticatorGetAssertion framework

Use a structure similar to libfido2, as usual.

Create toolchain files for ESP and nRF

Currently, we only have an avr.toolchain file to build the lib for the ATmega.
It would be nice if we could use the same system to build the library for the ESP and nRF as well (provided that the compilers are installed, of course).

Allow users to overwrite RNG implementation

Currently, we haven't implemented any randomness in the software. Nevertheless, we should allow users to define their own RNG implementation, possibly based on hardware support.

Linker Map Generation Not Working On macOS

On macOS, the LLVM linker does not have the -Map flag. Thus, in the feature/example-application branch, the link map generation does not work.

VSCode: Allow Include Path Arch

As a developer on an Arch Distro, I want to be able to develop the library in VSCode.

Thus, we need a configuration for VSCode that allows for better IntelliSense.

Improve docs

Check that subfolders contain README if necessary
Check main README (Examples have their own project structure and READMEs...)
Unify compiling instructions in a single file, currently the AVR instructions are in the main README, the other architectures in the examples folder
Maybe README in examples dir
NRF Readme should be better structured
~~Possibly Atmega examples~~

Implement FIDO Message Simulator

For testing the library on different platforms, it would be great to have a simulator that simulates the FIDO messages according to the standard.

This can be helpful when no real NFC connection is available.

Add A License

As we are actively developing this library and are hugely influenced by Yubico's libfido2 and also copied some code, we need to match their license (or something compatible).

They use a BSD 2-Clause license. I would therefore vote for the same license.

However, I would be glad for how to also attribute our own code. Dual-Copyright? How do we show which parts are from libfido2 and which changes are from us. This is pretty intermingled.

Generate randomness

We should probably use a PRNG with a truly random seed.

How to get the seed?
Look at existing papers

Makefile: Warnings = Errors

To improve and enforce code quality, it would be nice to have no warnings during compilation.
Thus, turning warnings into errors when compiling would be a good first step.

Add Citation File

See https://citation-file-format.github.io.

Add write functionality for authenticatorLargeBlob

It may be desirable to write data, such as un-/locking events, back to the large blob. That way, the data can be transported over the virtual network to some central system.

Implementation Notes

You'll likely want a structure similar to the already existing fido_dev_largeblob_get.

You might want to take a look at the implementation of the libfido2 in fido_dev_largeblob_set.

Library Does Not Build For Desktop (macOS, Linux)

When trying to build the library for x86 (cmake ..), the compilation process fails due to the measurements that are built for AVR and include avr/io.h.

Integrate Monocypher

Use a submodule
Remove everything not needed for ed25519
Make it compile
Think about an interface for crypto (also already existing crypto), for example for controllers with crypto coprocessors.

Add support for authenticator preference in the PIN protocol and cryptographic algorithms

Currently, we do not support any authenticator preference when choosing a cryptographic algorithm as well as a PIN protocol.

While the platform may specify its own preference, supporting the preference of the authenticator may be desirable to improve the speed (in case the authenticator has hardware support for certain algorithms for example).

Implementation Note

Currently, we use bitfields to store the support of certain algorithms. These bitfiels, however, do not provide any ranking.
As we only need the first algorithm from the authenticators list, which both parties support, a single additional field containing the preferred algorithm may be enough.

The struct is defined here and should likely be extended:

libmicrofido2/include/info.h

Lines 94 to 111 in bb3678d

 // See https://fidoalliance.org/specs/fido-v2.1-ps-20210615/fido-client-to-authenticator-protocol-v2.1-ps-20210615.html#authenticatorGetInfo 

 typedef struct fido_cbor_info { 

 fido_cbor_version_t versions; /* list of supported versions */ 

 fido_cbor_extension_t extensions; /* list of supported extensions */ 

 fido_cbor_transport_t transports; /* list of supported transports */ 

 unsigned char aaguid[16]; /* aaguid */ 

 fido_cbor_options_t options; /* list of supported options */ 

 uint64_t maxmsgsize; /* maximum message size */ 

 // TODO: How to support authenticator preference? 

 fido_cbor_pin_protocol_t protocols; /* supported pin protocols */ 

 // TODO: How to support authenticator preference? 

 fido_cbor_algorithm_t algorithms; /* list of supported algorithms */ 

 uint64_t maxcredcntlst; /* max credentials in list */ 

 uint64_t maxcredidlen; /* max credential ID length */ 

 uint64_t fwversion; /* firmware version */ 

 uint64_t maxcredbloblen; /* max credBlob length */ 

 uint64_t maxlargeblob; /* max largeBlob array length */ 

 } fido_cbor_info_t;

Add support for extensions and attestedCredentialData in assertion response

We currently do not support the extensions and attestedCredentialData in the authenticator data structure, as specified in WebAuthn § 6.1 Authenticator Data and CTAP 2.1 § 6.2.2 authenticatorGetAssertion Algorithm.

This is mostly due to its variable length, which makes it hard to store in fixed size stack-allocated structures, and also that we didn't need it for our PoC.

However, it might be desirable in the future to receive this data (such as extension outputs) and parse it in the relying party.

Implementation Note

The struct is defined here:

libmicrofido2/include/assertion.h

Lines 69 to 74 in bb3678d

 typedef struct fido_assert_auth_data { 

 uint8_t rp_id_hash[ASSERTION_AUTH_DATA_RPID_HASH_LEN]; 

 fido_assert_auth_data_flags_t flags; 

 uint32_t sign_count; 

 // TODO: extensions and attestedCredentialData not supported for now. 

 } fido_assert_auth_data_t;

The processing may happen here:

libmicrofido2/src/assertion.c

Lines 479 to 489 in bb3678d

 if (fido_check_flags(reply->auth_data.flags, assert->opt) < 0) { 

 fido_log_debug("%s: fido_check_flags", __func__); 

 return FIDO_ERR_INVALID_PARAM; 

 } 

 // TODO: Extensions not supported for now. 

 if (fido_check_rp_id(&(assert->rp_id), reply->auth_data.rp_id_hash) != 0) { 

 fido_log_debug("%s: fido_check_rp_id", __func__); 

 return FIDO_ERR_INVALID_PARAM; 

 }

Add RNG implementation

Currently, we do not provide any RNG implementation in software.

It may be useful to add one, which, however, would require some sort of entropy function. This must be implemented by the user of the library for the respective board.

See the following section in the code:

libmicrofido2/src/random.c

Lines 14 to 17 in 1916feb

 int fido_get_random(void *buf, size_t len) { 

 // TODO: Implement randomness here according to the standard. 

 return 0; 

 }

Prevent copying of the APDU data if possible

To reduce the amount of memory required on the stack, we may find a way to prevent copying the data when transmitting short APDUs.

Implementation Note

The copying happens in the tx_short_apdu function.

libmicrofido2/src/nfc.c

Lines 150 to 161 in bb3678d

 static int tx_short_apdu( 

 fido_dev_t *dev, 

 const iso7816_header_t *h, 

 const uint8_t *payload, 

 uint8_t payload_len, 

 uint8_t cla_flags 

 ) { 

 // TODO: Prevent copying if possible. 

 uint8_t apdu[5 + UINT8_MAX]; 

 uint8_t status_word[2]; 

 size_t apdu_len; 

 int ok = FIDO_ERR_TX;

This currently allocates (mostly, depending on the platform) 263 bytes, which may not be toooo bad.

	// See https://fidoalliance.org/specs/fido-v2.1-ps-20210615/fido-client-to-authenticator-protocol-v2.1-ps-20210615.html#authenticatorGetInfo
	typedef struct fido_cbor_info {
	fido_cbor_version_t versions; /* list of supported versions */
	fido_cbor_extension_t extensions; /* list of supported extensions */
	fido_cbor_transport_t transports; /* list of supported transports */
	unsigned char aaguid[16]; /* aaguid */
	fido_cbor_options_t options; /* list of supported options */
	uint64_t maxmsgsize; /* maximum message size */
	// TODO: How to support authenticator preference?
	fido_cbor_pin_protocol_t protocols; /* supported pin protocols */
	// TODO: How to support authenticator preference?
	fido_cbor_algorithm_t algorithms; /* list of supported algorithms */
	uint64_t maxcredcntlst; /* max credentials in list */
	uint64_t maxcredidlen; /* max credential ID length */
	uint64_t fwversion; /* firmware version */
	uint64_t maxcredbloblen; /* max credBlob length */
	uint64_t maxlargeblob; /* max largeBlob array length */
	} fido_cbor_info_t;

	typedef struct fido_assert_auth_data {
	uint8_t rp_id_hash[ASSERTION_AUTH_DATA_RPID_HASH_LEN];
	fido_assert_auth_data_flags_t flags;
	uint32_t sign_count;
	// TODO: extensions and attestedCredentialData not supported for now.
	} fido_assert_auth_data_t;

	if (fido_check_flags(reply->auth_data.flags, assert->opt) < 0) {
	fido_log_debug("%s: fido_check_flags", __func__);
	return FIDO_ERR_INVALID_PARAM;
	}

	// TODO: Extensions not supported for now.

	if (fido_check_rp_id(&(assert->rp_id), reply->auth_data.rp_id_hash) != 0) {
	fido_log_debug("%s: fido_check_rp_id", __func__);
	return FIDO_ERR_INVALID_PARAM;
	}

	int fido_get_random(void *buf, size_t len) {
	// TODO: Implement randomness here according to the standard.
	return 0;
	}

	static int tx_short_apdu(
	fido_dev_t *dev,
	const iso7816_header_t *h,
	const uint8_t *payload,
	uint8_t payload_len,
	uint8_t cla_flags
	) {
	// TODO: Prevent copying if possible.
	uint8_t apdu[5 + UINT8_MAX];
	uint8_t status_word[2];
	size_t apdu_len;
	int ok = FIDO_ERR_TX;

all-your-locks-are-belong-to-us / libmicrofido2 Goto Github PK

libmicrofido2's People

Contributors

Stargazers

Watchers

Forkers

libmicrofido2's Issues

Implementation Notes

Implementation Note

Implementation Note

Implementation Note

Recommend Projects

Recommend Topics

Recommend Org