Hi,
On Monday at 10am UK time, we will hold the Mbed TLS Tech Forum. This is an open forum conference call for anyone to participate; please reply here if there are any agenda topics you would like to raise.
Zoom details are in the TF calendar: https://www.trustedfirmware.org/meetings/mbed-tls-technical-forum/ or see below
Dave
Join Zoom Meeting https://linaro-org.zoom.us/j/99948462765?pwd=SGlHYlF1Z2owUDNFWWppaGlSRDh5UT0...
Meeting ID: 999 4846 2765 Passcode: 196117 One tap mobile +12532158782,,99948462765# US (Tacoma) +13462487799,,99948462765# US (Houston)
Dial by your location +1 253 215 8782 US (Tacoma) +1 346 248 7799 US (Houston) +1 669 900 9128 US (San Jose) +1 301 715 8592 US (Washington DC) +1 312 626 6799 US (Chicago) +1 646 558 8656 US (New York) 888 788 0099 US Toll-free 877 853 5247 US Toll-free Meeting ID: 999 4846 2765 Find your local number: https://linaro-org.zoom.us/u/anpWWkRdt
Hi Dave,
Is there any plan in the roadmap to update PSA API reference implementation in the Mbed TLS to have integrity check for in/out parameters to have better protection from Fault Injection?
Thanks Nazar
From: mbed-tls mbed-tls-bounces@lists.trustedfirmware.org On Behalf Of Dave Rodgman via mbed-tls Sent: Friday, December 3, 2021 12:54 PM To: mbed-tls-announce@lists.trustedfirmware.org; mbed-tls@lists.trustedfirmware.org Subject: [mbed-tls] Mbed TLS Tech Forum
Caution: This e-mail originated outside Infineon Technologies. Do not click on links or open attachments unless you validate it is safehttps://intranet-content.infineon.com/explore/aboutinfineon/rules/informationsecurity/ug/SocialEngineering/Pages/SocialEngineeringElements_en.aspx.
Hi,
On Monday at 10am UK time, we will hold the Mbed TLS Tech Forum. This is an open forum conference call for anyone to participate; please reply here if there are any agenda topics you would like to raise.
Zoom details are in the TF calendar: https://www.trustedfirmware.org/meetings/mbed-tls-technical-forum/ or see below
Dave
Join Zoom Meeting https://linaro-org.zoom.us/j/99948462765?pwd=SGlHYlF1Z2owUDNFWWppaGlSRDh5UT0...
Meeting ID: 999 4846 2765 Passcode: 196117 One tap mobile +12532158782,,99948462765# US (Tacoma) +13462487799,,99948462765# US (Houston)
Dial by your location +1 253 215 8782 US (Tacoma) +1 346 248 7799 US (Houston) +1 669 900 9128 US (San Jose) +1 301 715 8592 US (Washington DC) +1 312 626 6799 US (Chicago) +1 646 558 8656 US (New York) 888 788 0099 US Toll-free 877 853 5247 US Toll-free Meeting ID: 999 4846 2765 Find your local number: https://linaro-org.zoom.us/u/anpWWkRdt
Hi Nazar,
It’s not something that we have identified as a particular roadmap item. We do already do some parameter validation (see e.g. the code in library/psa_crypto.c) – is there a particular area where you think we have some gaps?
Thanks
Dave
From: "Nazar.Chornenkyy@infineon.com" Nazar.Chornenkyy@infineon.com Date: Friday, 3 December 2021 at 15:07 To: Dave Rodgman dave.rodgman@arm.com, "mbed-tls-announce@lists.trustedfirmware.org" mbed-tls-announce@lists.trustedfirmware.org Subject: RE: Mbed TLS Tech Forum
Hi Dave,
Is there any plan in the roadmap to update PSA API reference implementation in the Mbed TLS to have integrity check for in/out parameters to have better protection from Fault Injection?
Thanks Nazar
From: mbed-tls mbed-tls-bounces@lists.trustedfirmware.org On Behalf Of Dave Rodgman via mbed-tls Sent: Friday, December 3, 2021 12:54 PM To: mbed-tls-announce@lists.trustedfirmware.org; mbed-tls@lists.trustedfirmware.org Subject: [mbed-tls] Mbed TLS Tech Forum
Caution: This e-mail originated outside Infineon Technologies. Do not click on links or open attachments unless you validate it is safehttps://intranet-content.infineon.com/explore/aboutinfineon/rules/informationsecurity/ug/SocialEngineering/Pages/SocialEngineeringElements_en.aspx.
Hi,
On Monday at 10am UK time, we will hold the Mbed TLS Tech Forum. This is an open forum conference call for anyone to participate; please reply here if there are any agenda topics you would like to raise.
Zoom details are in the TF calendar: https://www.trustedfirmware.org/meetings/mbed-tls-technical-forum/ or see below
Dave
Join Zoom Meeting https://linaro-org.zoom.us/j/99948462765?pwd=SGlHYlF1Z2owUDNFWWppaGlSRDh5UT0...
Meeting ID: 999 4846 2765 Passcode: 196117 One tap mobile +12532158782,,99948462765# US (Tacoma) +13462487799,,99948462765# US (Houston)
Dial by your location +1 253 215 8782 US (Tacoma) +1 346 248 7799 US (Houston) +1 669 900 9128 US (San Jose) +1 301 715 8592 US (Washington DC) +1 312 626 6799 US (Chicago) +1 646 558 8656 US (New York) 888 788 0099 US Toll-free 877 853 5247 US Toll-free Meeting ID: 999 4846 2765 Find your local number: https://linaro-org.zoom.us/u/anpWWkRdt
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Hi Dave
I think it will be useful to include FIH library which is used in MCUboot and TFM projects and have it configurable by user to enable SW countermeasures for following items:
Asset
Security Properties
Category
Attack Vector (detailed description of exact possible way how to attack the asset)
Countermeasure (detailed description how to prevent attack)
Comments
Crypto API: PSA_SUCCES response value
Can't skip signature validation
Authenticity and Integrity
PSA API default value for PSA_SUCCESS is 0 which is sensitive to FI.
Change default value for PSA_SUCESS define from 0 to some complex value.
FI on PSA API response value during psa_verify_hash() or psa_hash_compare() API by Bootloader which leads to false image signature validation.
Change default API response psa_status_t type from int32_t to fih_int for all API
Crypto API: Image Hash parameter.
Integrity
Attacker can change by FI the hash address in the input parameter for psa_verify_hash() API and prepare fake hash in the not-secure area.
Change the type of *hash parameter to fih_uint in the all APIs
Integrity
Attacker can change by FI the input address in the input parameter for the psa_hash_compute() API and prepare fake image in the not-secure area.
Change the type of *input parameter to fih_uint in the all APIs
Consider to check integrity of all input parameters for all API. SW CRC algorithm can be used.
Integrity
Attacker can change by FI the input_length value in the input parameter for the psa_hash_compute() API and store fake data after the image which is attacked. Collision attack.
Change the type of input_lenght parameter to fih_uint in the all APIs
Integrity
Attacker can change by FI the alg value in the input parameter for the psa_hash_compute() API and use smaller hash algorithm.
Change the type of psa_algorithm_t parameter from uint32_t to fih_uint in the all APIs
Protect from leak of secrets.
Confidentiality
Attacker can request to hash secret data in the SE memory by providing their address in the input address for the psa_hash_compute() API.
Validate that the address of the input parameters belongs to not SE area.
Apply the same validation for all input addresses for all API.
Can't manipulate on SE functionality
Confidentiality
Attacker can request to store results of hash calculation in the SE memory by providing their address in the hash address for the psa_hash_compute() API.
Validate that the address of the hash parameters belongs to not SE area.
Apply the same validation for all output addresses for all API.
Crypto API: Attestation.
Can't allow signing of fake certificate
Confidentiality
Attacker can request sign operation of fake data by customer key from NSPE to TFM and then change keyID by FI to the RoT key during TFM to SE request by psa_sign_message() API.
Change the type of psa_key_id_t parameter from uint32_t to fih_uint in the all APIs
Countermeasure applicable for all API
Integrity
Attacker can change address for input data during attestation service request to SE by psa_sign_message() API.
Change the type of *input parameter to fih_uint in the psa_sign_message() API
Integrity
Attacker can change input data during attestation service request to SE by psa_sign_message() API.
Need to add CRC to check integrity on SE for input data for psa_sign_message() API.
Crypto API: Secure Storage
Confidentiality
Attacker can change by FI the alg value in the input parameter for the psa_chipher_decrypt() API from AES256 to AES128.
Change the type of psa_algorithm_t parameter from uint32_t to fih_uint in the all APIs
Crypto API: Key Management
Confidentiality
Attacker can try to disclosure private keys imported to SE by the psa_import_key() API.
Private keys should be stored in RRAM in shares and with checksums.
Integrity
Attacker can change private keys by FI to zero or change address of key imported to SE by the psa_import_key() API.
Change the type of *data parameter to fih_uint in the psa_import_key() API.
Add CRC to check integrity on SE for input data for psa_import_key() API.
Crypto API: Random Number
Can't allow to affect on generated random number
Integrity
Attacker can change by FI the address of output data generated by psa_generate_random() API.
Change the type of *output parameter to fih_uint in psa_generate_random() API.
Consider to check integrity of all output parameters for all API. SW CRC algorithm can be used.
Integrity
Attacker can change by FI the output data generated by psa_generate_random() API.
Need to add CRC to the output data for integrity check on SPE for output data for psa_generate_random() API.
Does it make sense?
Thanks Nazar
From: Dave Rodgman dave.rodgman@arm.com Sent: Tuesday, December 7, 2021 11:56 AM To: Chornenkyy Nazar (CSUKR CSS ICW SW FW) Nazar.Chornenkyy@infineon.com; mbed-tls-announce@lists.trustedfirmware.org Subject: Re: Mbed TLS Tech Forum
Caution: This e-mail originated outside Infineon Technologies. Do not click on links or open attachments unless you validate it is safehttps://intranet-content.infineon.com/explore/aboutinfineon/rules/informationsecurity/ug/SocialEngineering/Pages/SocialEngineeringElements_en.aspx.
Hi Nazar,
It’s not something that we have identified as a particular roadmap item. We do already do some parameter validation (see e.g. the code in library/psa_crypto.c) – is there a particular area where you think we have some gaps?
Thanks
Dave
From: "Nazar.Chornenkyy@infineon.commailto:Nazar.Chornenkyy@infineon.com" <Nazar.Chornenkyy@infineon.commailto:Nazar.Chornenkyy@infineon.com> Date: Friday, 3 December 2021 at 15:07 To: Dave Rodgman <dave.rodgman@arm.commailto:dave.rodgman@arm.com>, "mbed-tls-announce@lists.trustedfirmware.orgmailto:mbed-tls-announce@lists.trustedfirmware.org" <mbed-tls-announce@lists.trustedfirmware.orgmailto:mbed-tls-announce@lists.trustedfirmware.org> Subject: RE: Mbed TLS Tech Forum
Hi Dave,
Is there any plan in the roadmap to update PSA API reference implementation in the Mbed TLS to have integrity check for in/out parameters to have better protection from Fault Injection?
Thanks Nazar
From: mbed-tls <mbed-tls-bounces@lists.trustedfirmware.orgmailto:mbed-tls-bounces@lists.trustedfirmware.org> On Behalf Of Dave Rodgman via mbed-tls Sent: Friday, December 3, 2021 12:54 PM To: mbed-tls-announce@lists.trustedfirmware.orgmailto:mbed-tls-announce@lists.trustedfirmware.org; mbed-tls@lists.trustedfirmware.orgmailto:mbed-tls@lists.trustedfirmware.org Subject: [mbed-tls] Mbed TLS Tech Forum
Caution: This e-mail originated outside Infineon Technologies. Do not click on links or open attachments unless you validate it is safehttps://intranet-content.infineon.com/explore/aboutinfineon/rules/informationsecurity/ug/SocialEngineering/Pages/SocialEngineeringElements_en.aspx.
Hi,
On Monday at 10am UK time, we will hold the Mbed TLS Tech Forum. This is an open forum conference call for anyone to participate; please reply here if there are any agenda topics you would like to raise.
Zoom details are in the TF calendar: https://www.trustedfirmware.org/meetings/mbed-tls-technical-forum/ or see below
Dave
Join Zoom Meeting https://linaro-org.zoom.us/j/99948462765?pwd=SGlHYlF1Z2owUDNFWWppaGlSRDh5UT0...
Meeting ID: 999 4846 2765 Passcode: 196117 One tap mobile +12532158782,,99948462765# US (Tacoma) +13462487799,,99948462765# US (Houston)
Dial by your location +1 253 215 8782 US (Tacoma) +1 346 248 7799 US (Houston) +1 669 900 9128 US (San Jose) +1 301 715 8592 US (Washington DC) +1 312 626 6799 US (Chicago) +1 646 558 8656 US (New York) 888 788 0099 US Toll-free 877 853 5247 US Toll-free Meeting ID: 999 4846 2765 Find your local number: https://linaro-org.zoom.us/u/anpWWkRdt
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Hi Nazar,
Thanks for the detailed suggestions.
This level of fault injection defense is something we don’t currently aim to protect against. The suggestions below would also impact the PSA Crypto API. So I think adding these kinds of defenses would be a significant task – not something that we would be able to have on our roadmap for now.
Dave
From: "Nazar.Chornenkyy@infineon.com" Nazar.Chornenkyy@infineon.com Date: Tuesday, 7 December 2021 at 11:23 To: Dave Rodgman dave.rodgman@arm.com, "mbed-tls-announce@lists.trustedfirmware.org" mbed-tls-announce@lists.trustedfirmware.org Subject: RE: Mbed TLS Tech Forum
Hi Dave
I think it will be useful to include FIH library which is used in MCUboot and TFM projects and have it configurable by user to enable SW countermeasures for following items:
Asset Security Properties Category Attack Vector (detailed description of exact possible way how to attack the asset) Countermeasure (detailed description how to prevent attack) Comments Crypto API: PSA_SUCCES response value Can't skip signature validation Authenticity and Integrity PSA API default value for PSA_SUCCESS is 0 which is sensitive to FI. Change default value for PSA_SUCESS define from 0 to some complex value. FI on PSA API response value during psa_verify_hash() or psa_hash_compare() API by Bootloader which leads to false image signature validation. Change default API response psa_status_t type from int32_t to fih_int for all API Crypto API: Image Hash parameter. Integrity Attacker can change by FI the hash address in the input parameter for psa_verify_hash() API and prepare fake hash in the not-secure area. Change the type of *hash parameter to fih_uint in the all APIs Integrity Attacker can change by FI the input address in the input parameter for the psa_hash_compute() API and prepare fake image in the not-secure area. Change the type of *input parameter to fih_uint in the all APIs Consider to check integrity of all input parameters for all API. SW CRC algorithm can be used. Integrity Attacker can change by FI the input_length value in the input parameter for the psa_hash_compute() API and store fake data after the image which is attacked. Collision attack. Change the type of input_lenght parameter to fih_uint in the all APIs Integrity Attacker can change by FI the alg value in the input parameter for the psa_hash_compute() API and use smaller hash algorithm. Change the type of psa_algorithm_t parameter from uint32_t to fih_uint in the all APIs Protect from leak of secrets. Confidentiality Attacker can request to hash secret data in the SE memory by providing their address in the input address for the psa_hash_compute() API. Validate that the address of the input parameters belongs to not SE area. Apply the same validation for all input addresses for all API. Can't manipulate on SE functionality Confidentiality Attacker can request to store results of hash calculation in the SE memory by providing their address in the hash address for the psa_hash_compute() API. Validate that the address of the hash parameters belongs to not SE area. Apply the same validation for all output addresses for all API. Crypto API: Attestation. Can't allow signing of fake certificate Confidentiality Attacker can request sign operation of fake data by customer key from NSPE to TFM and then change keyID by FI to the RoT key during TFM to SE request by psa_sign_message() API. Change the type of psa_key_id_t parameter from uint32_t to fih_uint in the all APIs Countermeasure applicable for all API Integrity Attacker can change address for input data during attestation service request to SE by psa_sign_message() API. Change the type of *input parameter to fih_uint in the psa_sign_message() API Integrity Attacker can change input data during attestation service request to SE by psa_sign_message() API. Need to add CRC to check integrity on SE for input data for psa_sign_message() API. Crypto API: Secure Storage Confidentiality Attacker can change by FI the alg value in the input parameter for the psa_chipher_decrypt() API from AES256 to AES128. Change the type of psa_algorithm_t parameter from uint32_t to fih_uint in the all APIs Crypto API: Key Management Confidentiality Attacker can try to disclosure private keys imported to SE by the psa_import_key() API. Private keys should be stored in RRAM in shares and with checksums. Integrity Attacker can change private keys by FI to zero or change address of key imported to SE by the psa_import_key() API. Change the type of *data parameter to fih_uint in the psa_import_key() API. Add CRC to check integrity on SE for input data for psa_import_key() API. Crypto API: Random Number Can't allow to affect on generated random number Integrity Attacker can change by FI the address of output data generated by psa_generate_random() API. Change the type of *output parameter to fih_uint in psa_generate_random() API. Consider to check integrity of all output parameters for all API. SW CRC algorithm can be used. Integrity Attacker can change by FI the output data generated by psa_generate_random() API. Need to add CRC to the output data for integrity check on SPE for output data for psa_generate_random() API.
Does it make sense?
Thanks Nazar
From: Dave Rodgman dave.rodgman@arm.com Sent: Tuesday, December 7, 2021 11:56 AM To: Chornenkyy Nazar (CSUKR CSS ICW SW FW) Nazar.Chornenkyy@infineon.com; mbed-tls-announce@lists.trustedfirmware.org Subject: Re: Mbed TLS Tech Forum
Caution: This e-mail originated outside Infineon Technologies. Do not click on links or open attachments unless you validate it is safehttps://intranet-content.infineon.com/explore/aboutinfineon/rules/informationsecurity/ug/SocialEngineering/Pages/SocialEngineeringElements_en.aspx.
Hi Nazar,
It’s not something that we have identified as a particular roadmap item. We do already do some parameter validation (see e.g. the code in library/psa_crypto.c) – is there a particular area where you think we have some gaps?
Thanks
Dave
From: "Nazar.Chornenkyy@infineon.commailto:Nazar.Chornenkyy@infineon.com" <Nazar.Chornenkyy@infineon.commailto:Nazar.Chornenkyy@infineon.com> Date: Friday, 3 December 2021 at 15:07 To: Dave Rodgman <dave.rodgman@arm.commailto:dave.rodgman@arm.com>, "mbed-tls-announce@lists.trustedfirmware.orgmailto:mbed-tls-announce@lists.trustedfirmware.org" <mbed-tls-announce@lists.trustedfirmware.orgmailto:mbed-tls-announce@lists.trustedfirmware.org> Subject: RE: Mbed TLS Tech Forum
Hi Dave,
Is there any plan in the roadmap to update PSA API reference implementation in the Mbed TLS to have integrity check for in/out parameters to have better protection from Fault Injection?
Thanks Nazar
From: mbed-tls <mbed-tls-bounces@lists.trustedfirmware.orgmailto:mbed-tls-bounces@lists.trustedfirmware.org> On Behalf Of Dave Rodgman via mbed-tls Sent: Friday, December 3, 2021 12:54 PM To: mbed-tls-announce@lists.trustedfirmware.orgmailto:mbed-tls-announce@lists.trustedfirmware.org; mbed-tls@lists.trustedfirmware.orgmailto:mbed-tls@lists.trustedfirmware.org Subject: [mbed-tls] Mbed TLS Tech Forum
Caution: This e-mail originated outside Infineon Technologies. Do not click on links or open attachments unless you validate it is safehttps://intranet-content.infineon.com/explore/aboutinfineon/rules/informationsecurity/ug/SocialEngineering/Pages/SocialEngineeringElements_en.aspx.
Hi,
On Monday at 10am UK time, we will hold the Mbed TLS Tech Forum. This is an open forum conference call for anyone to participate; please reply here if there are any agenda topics you would like to raise.
Zoom details are in the TF calendar: https://www.trustedfirmware.org/meetings/mbed-tls-technical-forum/ or see below
Dave
Join Zoom Meeting https://linaro-org.zoom.us/j/99948462765?pwd=SGlHYlF1Z2owUDNFWWppaGlSRDh5UT0...
Meeting ID: 999 4846 2765 Passcode: 196117 One tap mobile +12532158782,,99948462765# US (Tacoma) +13462487799,,99948462765# US (Houston)
Dial by your location +1 253 215 8782 US (Tacoma) +1 346 248 7799 US (Houston) +1 669 900 9128 US (San Jose) +1 301 715 8592 US (Washington DC) +1 312 626 6799 US (Chicago) +1 646 558 8656 US (New York) 888 788 0099 US Toll-free 877 853 5247 US Toll-free Meeting ID: 999 4846 2765 Find your local number: https://linaro-org.zoom.us/u/anpWWkRdt
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
mbed-tls-announce@lists.trustedfirmware.org
-
Dave Rodgman -
Nazar.Chornenkyy＠infineon.com