Dear all,
please find below the notes that I took during the meeting. The TF-PSA-Crypto-Drivers presentation has been shared already. For next month we are still planning to have a similar session for ADAC, still pending the slides to be polished and shared by Frank.
Thanks,
Antonio
Attendees:
David Brown
Antonio
Frank
PJ Bringer
Kangkang
Eric Finco
Janos
Vincent Berthelot (STM)
Julius Werner
Dominik Ermel
Joanna
Ruchika
Lionel
Shebu
Eric F. / David B. --> MCUboot vulnerabilities (5 reports from STM, no disclosure. 1 for which no feedback yet. David V. analysis posted, but no disclosure -> STM requires to understand how to proceed further)
1 was fixed and released (Injection attack)
For a few of them we need to publish disclosure -> Downgrade prevention can be bypassed. Needs to be disclosed as ST needs to position with their customers. David B. I will go ahead and disclose, we can have a SW workaround. Vincent is ok with it. Other ones are disclosed and no blocker on that, there is a way forward.
TF-PSA-Crypto-Drivers discussion
-> Go through the presentation again. TF-PSA-Crypto repo in the context of Mbed TLS 4.0
Ruchika agrees to proposal idea
Janos on technical: the drivers API are still under development, not feature complete. Details for further improvement, tech forum / github -> direction of that will influence the repo proposal as well
repo / vendor focused. Allow for generated and checked in version of driver_wrappers
--> Stabilize the PSA Crypto drivers API (currently it's all internal)
--> PSA Crypto core vs drivers responsibilities
--> Licensing, binary hosting, docs, and configurability
Vincent: Do you plan to propose a transition period in order to let vendor to move?
Plan discussions in TF-M tech forum / Mbed TLS
--> Any license? BSD-3. -> Taken through the board. Standard permissive licenses ok, but more complex case?
--> Build at least, testing possible. Not have code that is left there without testing
--> Proposal idea is welcomed by current providers of drivers
Dear all,
apologies for the delay in getting this out. Please find below the minutes for last TSC meeting and attached both presentations from Akanksha (TF-A / TS roadmap update) and Frank (TF-PSA-Crypto-Drivers proposal).
I also wanted to remind you that the TF-PSA-Crypto-Drivers topic will have a follow up in the next TSC meeting (20th of June), as last time we did not have any time for discussion and we had to rush the last bits of the presentation, so we're aiming to do a replay / discussion focused session this time: I'd like to invite any interested party to review the material before the meeting.
* TF-A and Trusted Services roadmap
* Proposed collaboration on maintenance / further development of ADAC. @Frank Audun – are you available for this?
* Also, hosting PSA Crypto Drivers
Present:
Dan Handley
Antonio
Akanksha
Anton
Matteo
Eric Finco
Maulik Patel
Kankkang Shen
Camille Greusard
Olivier Deprez
Shebu
Joanna
Frank Audun (Nordic)
Dominic Ermel
Julius Werner
* Akanksha and Dan presented these slides
* More non-Arm Hafnium contributions than previously.
* Eric: Who from?
* I believe Nvidia
* Release 2.11 should be available next week.
* Olivier: TF-A v2.11 trees were tagged today. Release announcement is imminent, worst case next Tuesday!
* GIC v3.3 NMI DI/II gated on some kernel investigations
* Frank presented these slides
* Calling from Ireland
* 1st topic is PSA ADAC. Also to talk about TF PSA Crypto Drivers
* Question of whether ADAC is properly supported in TF-M. We want this a front-end feature in TF-M
* Dan: How platform specific is this?
* If you have e.g. a standard life cycle and crypto concepts (e.g. PSA Crypto) then can have a common front end.
* Anton: When you say platform RoT, do you mean PSA RoT?
* Yes
* Antiono: The “built in keys” support has been on the Mbed TLS roadmap for some time now.
* Yes, we’ll continue to push for this
Thanks,
Antonio
Hi all
Let me know if you have any topics for this Thursday's meeting. So far we have:
* TF-A and Trusted Services roadmap
* Proposed collaboration on maintenance / further development of ADAC. @Frank Audun - are you available for this?
Regards
Dan.
Hi all
One of the topics for the TSC meeting this Thursday (9th May) was the TF-A / Trusted Services roadmap but our technology manager won't be available. Can we reschedule this (again) to the 23rd May, post Linaro Connect?
We'll wait a day or two for feedback before rescheduling.
Regards
Dan.
Hi all
We currently do have any topics ready to discuss in tomorrow's meeting. The next scheduled roadmap update is TF-A/Trusted Services but our tech manager is not ready to do this tomorrow. Therefore I'm proposing to cancel unless anyone has any urgent topics?
Also, the following TSC is scheduled for 16th May, which is during Linaro Connect. I propose bringing this forward a week to the same time on 9th May. Let me know if you have any issues with this. Also, at the last Linaro Connect, we had an informal TF.org Board/TSC meeting for those present. Is there any interest in doing this again?
Regards
Dan.
Present:
Shebu Varghese Kuriakose (Arm)
Dan Handley (Arm)
Dave Rodgman (Arm)
Antonio De Angelis (Arm)
Frank Audun (Nordic)
PJ Bringer (ProvenRun)
Janos Follath (Arm)
Andrej Butok (NXP)
Joanna Farley (Arm)
David Brown (Linaro)
Julius Werner (Google)
Ruchika Gupta (NXP)
Michael Thomas (Renesas)
Dominik Ermel (Nordic)
Moritz Fischer (Google)
Eric Finco (ST)
Shebu gave Mbed TLS roadmap update (attached):
* Thread safety on PSA Crypto
* Allow building without software crypto implementation
* Enable TLS 1.3 by default
* Arm v8-A crypto extension support
Shebu: Want to align PSA Crypto headers in TF-M and Mbed TLS in the next TLS of both projects
Shebu: Would like feedback on the PSA Crypto thread safety when teams start to use it
Frank: Regarding schedule, we want to align with Zephyr LTS. Can we get Mbed TLS and TF-M LTS into Zephyr LTS?
Frank: Will propose to Zephyr security committee that Zephyr takes Mbed TLS 3.6 anyway even though it's not quite ready
Shebu: Understand that there were issues in the past when Zephyr took a non-LTS Mbed TLS
Shebu: Definitely happy to line up the ducks here
Shebu: Hopefully when we do TF-M LTS in April there will be enough buffer to get this into Zephyr LTS
Shebu: There will be a change in the Mbed TLS LTS cadence so both Mbed TLS and TF-M LTS cadence will be every 18 months.
Frank: Need some out of tree patches to enable certain TLS/DTLS use-cases using PSA Crypto API
Shebu: Think we're in a better place than we were with Mbed TLS 3.1/3.2
Shebu: After 3.6 LTS is out, it implies all new features will be on the 4.0 codeline
Shebu: Need to do a lot of planning before we can give dates for this
Shebu: 4.0 will make PSA Crypto the default main crypto API.
DaveR: I think we're agreed we want to remove (not deprecate) the legacy cipher interfaces
DaveR: A lot of config options for legacy interface will be removed (PSA_WANT_* will be the default way of configuring)
Shebu: Please check for notifications in the mailing list about interface deprecation proposals
Ruchika: With respect to PSA Crypto repo separation, will people be able to integrate Mbed TLS with their own PSA Crypto implementation?
Janos: Probably not a goal of 4.0 but eventually would like to make that possible.
Janos: 4.0 is already quite ambitious so that is probably not realistic
Ruchika: Trying to enforce the removal of usage of the legacy interfaces, so wanted to confirm that's the plan
DaveR: Yes, that's the plan
Shebu: If anyone is able to help contribute to 4.0, that will help get it out the door earlier
Shebu: I know Ruchika was asking about benchmarking support but that's currently a future item in the roadmap
Frank: Don't see any PQC on this roadmap.
Frank: There is one implementation but not a standardised PSA Cypto API. Will it be moved?
Shebu: The algorithm in question (LMS) was implemented to unblock Arm's Runtime Security Engine (RSE) team but other algorithms are not on the roadmap yet.
Frank: Will there be a PSA Crypto API 1.3 to fix issues in the PSA API GitHub?
Shebu: I'm sure eventually there will be a PSA Crypto API 1.3. We'll add this to the roadmap.
AOB:
Dan: Don finally removed support for Phabricator (developer.trustedfirmware.org) and put it in an archive.
Dan: There are still a few references to this being fixed in the project documentation and website.
Dan: When complete, individual projects should notify their respective MLs.
Dan: We added security.txt file to the website. It's the standard approach to providing security information for issue reporting.
https://www.trustedfirmware.org/.well-known/security.txt
Dan: cgit is being deprecated too. https://git.trustedfirmware.org/ will soon point to gitiles (the in-built Gerrit web interface) instead.
Dan: git commands should continue to work as before.
Dan: Redirects will be in place for high level links to projects/files.
Dan: More specific links to versions/branches may get broken.
Dan: We're doing this to enable support for private branches/repos in Gerrit. Cgit bypasses Gerrit access permissions.
Frank: We were part of defining the ADAC spec. Before it was moved to TF.org ownership.
Frank: It currently seems a bit disconnected from TF-M. It still uses legacy Mbed TLS APIs.
Frank: Any plans to fix this? We're willing to help.
Frank: Would like this to be an officially supported feature.
Shebu: It's not abandoned. People are still working on it.
Shebu: It moved to tf.org to become a reference implementation.
Shebu: We put it in a separate repo as we thought other projects might be able to use it
Shebu: Currently only has MUSCA platforms support
Shebu: We want to enable using this at runtime not just boot time
Shebu: Agree we need to move to using PSA Crypto API. Think there also some usage of other non-MBed TLS Crypto API
Dan: Is this on the roadmap?
Shebu: ADAC runtime support is on the roadmap. We will have to look into legacy API deprecation.
Shebu: Think we're looking for co-maintainers for this. Only a couple of Arm people are on it.
Frank: We can put forward a couple of candidates
Frank: Visibility within TF-M project is what we'd like. We want to make this generically usable.
Frank: Certificate management testing scripts are still internal to the authors of the spec. It might make sense for TF.org to own them publicly, although they might give the wrong impression
Frank: We can take the details offline but we're happy that ADAC is still being developed
Shebu: Linaro connect is approaching. We have a couple of session submissions around TF.org
Hi all,
This is the agenda we have for tomorrow's TSC meeting:
*
mbed TLS roadmap update (@Shebu)
*
AOB
Please let me know if you have any specific topic you would like to add or have it discussed.
Thanks, Antonio
Dear all,
this is a reminder to call for an agenda for the upcoming TSC meeting. The Mbed TLS roadmap update originally planned has been postponed to the March TSC, so at the moment the agenda is empty. If you have anything to discuss please let me know by Tomorrow (14th) COB.
Thanks, Antonio
Hi all
Below are the minutes for last week's meeting (thanks to Antonio).
Regards
Dan.
=====
Shebu Varghese Kuriakose (Arm)
Dan Handley (Arm)
Antonio De Angelis (Arm)
Joanna Farley (Arm)
Pierre-Julien Bringer (ProvenRun)
Camille Greusard (ProvenRun)
Julius Werner (Google)
Moritz Fischer (Google)
Jidong Sun (Google)
KangKang Shen (FutureWei)
Eric Finco (ST)
Frank Audun (Nordic)
Andrej Butok (NXP)
Silvano Di Ninno (NXP)
David Brown (Linaro)
Dan: Welcome to Jidong (new Google rep, replacing Okash) and new members ProvenRun (Pierre-Julien and Camille)
Dan: Starting a new round of roadmap updates, starting with TF-M
Shebu presented TF-M roadmap (attached)
Shebu: Achievements of tf-m 2.0.0:
* Reduction in size for ECDSA using P256M
* Usage of split-build
* New mailbox non-secure agent api
* Non-secure interrupt latency for isolation level > 1
Shebu: Introduction and planning for LTS
* Previous plan was do first LTS in Jan. New plan is April
Shebu: Work continues on Hybrid Platforms
Shebu: TLS connection use case
* Realigning the full headers mainly
Shebu: Impact of LTS on PSA Certified.
* LTS released every 18 months and supported for 36 months. Bug fixes and security fixes backported.
* This will be delta evaluations for the PSA labs, and this will allow partners to keep certification on that branch
Shebu: Platform ports will be allowed on this LTS Branch when those happen
Eric: Sounds good. Will Mbed TLS will move to a similar cadence?
Shebu: Yes. Mbed TLS has had LTS for a long time, but now it's moving to 3 year support, which aligns with TF-M.
Shebu: Will have a new one every 18months (lifetime 3 years).
Dan: Also welcome to Frank, the new rep from Nordic...
Frank: Is there a lead time on the PSA labs to allow such cadence?
Shebu: Important consideration. If there's an external vulnerability, we might not be in control of public disclosure.
Shebu: TF.org security incident process will follow its own process. TF-M will push out it's fix as soon as it can. Trusted Stakeholders will get the fix under embargo.
Shebu: Not necessarily aligned with Trusted Lab release schedule.
Shebu: We have been clear with PSA certified program, but currently there is no guarantee on time needed for the new release to be validated before the vulnerability goes public.
Frank: I'm less concerned about security handling. More that companies might ask the same service from the same company at the same time.
Shebu: TrustCB have been very engaged with the process. You're right this is a concern.
Shebu: But it's not a separate process that everybody has to do when there's a new release. All can benefit from the same handling.
Shebu: PSA labs can share reports generated by other labs so easing the pressure around recertification for platforms
Shebu: If it's a generic fix, it will get applied to all platforms.
Frank: Good, there's some sharing of effort.
Shebu: In next release can move from RSA to ECDSA
* Blocked on moving to this lightweight PSA crypto layer.
Antonio: Looks like it will be in TF-M 2.1
Shebu: Are we expecting some mem size reduction?
Antonio: At least the same size or lower.
Eric: Will Cryptocell refactoring be done without breaking compatibility?
Shebu: Yes, we already moved to PSA Crypto interface before so this is just changing things underneath
Shebu: Enabling TF-M on RSE (formally known as RSS) is not shown on the roadmap
* RSE is firmware for a complete secure enclave. RSE has been presented in one of the previous TF-M tech forums
ProvenRun introduction (Camille):
* We're a French company providing security services. e.g. for Defence, IoT, ...
* Providers of secure operating systems for Cortex-M.
* Currently we integrate TF-M partitions from the upstream repository. This solution is currently delivered to STM (using our own SPM + TF-M partitions).
* Compatibility with official TF-M is important
* We're interested in technical subjects and future developments. Happy with the TF-M presentation contents just showed
* Interested in TF-M community and being a contributor in future.
* Do not hesitate to get in touch. Either Camille or Pierre-Julien will attend this TSC
Shebu: On the A profile, is that a trusted execution environment or a trusted operating system?
Camille: Just M-profile, it was a misunderstanding earlier.
Frank also briefly introduced Nordic/himself:
Frank: Nordic started on tiny ASICs. Now have more and more complex devices.
* Interested in MbedTLS, MCUBoot, TF-M, Zephyr
* Managed to get optimised signature verification working in products
* Very open source oriented.
Dan: Silvano is also new to the TSC
Silvano: Just filling in for Ruchika this time.
Dan gave a Phabricator migration update (Dan)
* Migration going well.
* Just TF-A and Mbed TLS project pages remaining.
* Created https://github.com/TrustedFirmware/tf_docs rendered in readthedocs for generic content like the Security Center.
* Hope to complete before end of Q1 so we can retire Phabricator (https://developer.trustedfirmware.org/)
