nRF Secure Bootloader - Immutable bootloader with Mcuboot as second stage

Hi,

We are trying out some configurations for building and implementing Immutable Bootloader with Second stage upgradeable bootloader MCUboot. We are building the bootloader according to docs for first stage and 2nd stage. Thus, when changing the signing mechanism to ED25519 the build fails because of flash overflow, is there a way to use ED25519? 

The crypto client, is there support for ED25519? 

Best regards

Parents
  • Thinking out loud, would it be possible to create a handler similiar to ECDSA SECP256R1 in nrfdir/subsys/bootloader/bl_crypto_client?

    #ifdef CONFIG_BL_SECP256R1_EXT_API_REQUIRED
    EXT_API_REQ(BL_SECP256R1, 1, struct bl_secp256r1_ext_api, bl_secp256r1);
    
    int bl_secp256r1_validate(const uint8_t *hash, uint32_t hash_len,
    			const uint8_t *public_key, const uint8_t *signature)
    {
    	return bl_secp256r1->ext_api.bl_secp256r1_validate(hash, hash_len,
    							public_key, signature);
    }
    #endif

    For ED25519
    #ifdef CONFIG_BL_ED25519_EXT_API_REQUIRED
    EXT_API_REQ(BL_ED25519, 1, struct bl_ed25519_ext_api, bl_ed25519);
    
    int bl_ed25519_validate(const uint8_t *hash, uint32_t hash_len,
    			const uint8_t *public_key, const uint8_t *signature)
    {
    	return bl_ed25519->ext_api.ED25519_verify(hash, hash_len,
    							public_key, signature);
    }
    #endif
    Because it seems that there are dependencies on size optimization in relation to NRF Crypto and ECDSA Kconfigs. 
Reply
  • Thinking out loud, would it be possible to create a handler similiar to ECDSA SECP256R1 in nrfdir/subsys/bootloader/bl_crypto_client?

    #ifdef CONFIG_BL_SECP256R1_EXT_API_REQUIRED
    EXT_API_REQ(BL_SECP256R1, 1, struct bl_secp256r1_ext_api, bl_secp256r1);
    
    int bl_secp256r1_validate(const uint8_t *hash, uint32_t hash_len,
    			const uint8_t *public_key, const uint8_t *signature)
    {
    	return bl_secp256r1->ext_api.bl_secp256r1_validate(hash, hash_len,
    							public_key, signature);
    }
    #endif

    For ED25519
    #ifdef CONFIG_BL_ED25519_EXT_API_REQUIRED
    EXT_API_REQ(BL_ED25519, 1, struct bl_ed25519_ext_api, bl_ed25519);
    
    int bl_ed25519_validate(const uint8_t *hash, uint32_t hash_len,
    			const uint8_t *public_key, const uint8_t *signature)
    {
    	return bl_ed25519->ext_api.ED25519_verify(hash, hash_len,
    							public_key, signature);
    }
    #endif
    Because it seems that there are dependencies on size optimization in relation to NRF Crypto and ECDSA Kconfigs. 
Children
Related