Hi All,
Any agenda items for this week?
I have following on my list
* Provisioning. This is now running as a separate meeting, hopefully you have received invite for that. We can have a quick summary of the status.
* TF-M coding standard. Following up from the mailing list thread about weak symbols.
* Enabling IDE support for TF-M. This topic was raised in the workshop in Lyon. I would like to summarize and discuss possible options, next steps etc.
Thanks,
Abhishek
Attendees
Abhishek Pandit (Arm)
Christian Daudt (Cypress)
Dan Handley (Arm)
David Brown (Linaro)
Kevin Townsend (Linaro)
Joakim Bech (Linaro)
Eric Finco (ST)
Mark Grosen (TI)
Bill Mills (TI)
Bill Fletcher (Linaro Community Projects)
Agenda
CNA training
Provisioning
ELC TF-M workshop in Lyon
Git process flow
OP-TEE git update
Notes
DB: CNA training? CVE Numbering Authorities. Able to assign CVEs in blocks
of 10 without going through a minder. No charge. Same amount of time as we
should be spending on CVEs anyway.
JB/DH: Think it’s a good idea.
DH: Would like to establish who is on the security mailing lists.
JB: Have had bad experience working through Mitre.
CD: To clarify this the scope is TF-A, TF-M, OP-TEE
DB: Yes.
CD: Not much purpose to get CVEs if we don’t have anyone to do anything on
them.
DB: CF Zephyr …
DH: Will send email to allow people to formally sign off on this
DB: I would like to have a discussion about provisioning. Right now, it
seems that the only way we specify a device identifying itself is by giving
its public key, which would require that every device to be provisioned be
entered into some kind of database before it could be known. Instead I'd
like to propose that we have a way of storing and retrieving an X.509
certificate, which would have that public key in it, along with a signature
chain that could be used to indicate that this device is trusted. This is
commonly done in deployed devices, and we might as well add this
functionality now.
AP: Had proposed a provisioning-specific slot, but no one registered
interest. Will still schedule this.
DB: Have defined attestation token signed with a private key internal to
device. There is also a public key. If only this, it has to be known by the
entity on the other side to know a valid device. Preferred approach is a
certificate - that public key signed by an authority.
https://github.com/microbuilder/zephyr/blob/tfm-psa-level-1/samples/tfm_int…
Need to “get a certificate” … is this a trusted device?
DB: Different to e.g. MQTT using a TLS certificate. Need to be flexible
allowing a public key registration.
KT: How to know if a device should be joining the network with just public
key.
DB: Unless a channel from the factory with a list of trusted devices.
DB: May also need a mechanism to update these keys
BM: Overlap with Intel?
JB: Yes. Pelion was the collaboration between Intel and Arm
BM: Think the base concept was simpler.
JB: Talk to Reed Hinkel about the LEDGE presentation session on this.
EF: Got it through the mailing list of LEDGE.
AP: Would like to do this as a provisioning subgroup and then ask the TSC
if they want to proceed. Happy for David or Kevin to lead the discussion.
CD: Shall we see if can have a similar discussion to the one we had at
Connect
JB: Can ask Francois or Reed to see if they can help us.
AP: If you know someone who is interested, we should extend to wider than
TSC. Will schedule the meeting.
MG:
https://www.intel.com/content/dam/www/public/us/en/documents/idz/iot/briefs…
AP: TF-M workshop in Lyon after ELC. Will discuss the outcomes at next TSC.
MG: Git flow. How to know when it’s a good time to integrate with the TF-M
workflow. Aren’t many tags etc. Have tried with some issues. Are there
engineering builds, alpha builds?
AP: Can take guidance as TF-A which is more mature. Need to decide if 6
monthly test cycle as TF-A. Need solid branches to base work on. Dual core
work ongoing on a branch. Posted requests for review but there were no
reviews. Has been no drive to fix the methodology yet.
AP: CI running but it’s problematic with MPS2 at the moment.
CD: But no formal cycles yet
AP: Arm stretched to support the feature requests at the moment. Will talk
to Shebu to structure the roadmap in order to have something stable.
JB: Forked OP-TEE gits are now at git.trustedfirmware.org
--
[image: Linaro] <http://www.linaro.org/>
*Bill Fletcher* | *Field Engineering*
T: +44 7833 498336 <+44+7833+498336>
bill.fletcher(a)linaro.org | Skype: billfletcher2020
I would like to have a discussion about provisioning. Right now, it seems
that the only way we specify a device identifying itself is by giving its
public key, which would require that every device to be provisioned be
entered into some kind of database before it could be known.
Instead I'd like to propose that we have a way of storing and retrieving an
X.509 certificate, which would have that public key in it, along with a
signature chain that could be used to indicate that this device is trusted.
This is commonly done in deployed devices, and we might as well add this
functionality now.
David
On Tue, Oct 8, 2019 at 5:00 PM Abhishek Pandit via TSC <
tsc(a)lists.trustedfirmware.org> wrote:
> Hi All,
>
>
>
> Any agenda items for the meeting this week?
>
>
>
> Thanks,
>
> Abhishek
> --
> TSC mailing list
> TSC(a)lists.trustedfirmware.org
> https://lists.trustedfirmware.org/mailman/listinfo/tsc
>
Attendees
Abhishek Pandit (Arm)
Chris (Cypress)
Ray Ngun (Cypress)
Christian Daudt (Cypress)
Dan Handley (Arm)
David Brown (Linaro)
Joakim Bech (Linaro)
Julius Werner (Google)
Lionel Debieve (ST)
Rajeev Gulati (Data I/O)
Bill Fletcher (Linaro Community Projects)
Notes
Ray: Cypress TF M enablement on PSoC6 dual core (slides circulated
separately)
Chris: PSoC as SMPUs based on v6/v7 ones. Has alignment/size constraints.
Difficult to arrange 1M flash to manage protection regions. Much easier
with the v8.
Build system work complicated.
AP: Getting feedback on build system elsewhere. Not sure if it is CMake.
What’s your view?
Chris: CMake isn’t particularly intuitive. Building secure side veneers -
had to figure out to separate those out.
AP: V8m crashes are hard to debug. Maybe worth having a focus group on
build system.
CD: Implicit assumptin that secure and non-secure are the same ilk and not
the case for PSoC6. Does not have the same facilities/options.
AP: Assumed secured binary comes from one entity and non-secure from
another. That’s how it evolved. Secure people give config and API. Agreed
it’s very v8m centric.
CD: Patches should fix that
AP: Will follow up on why the patches are still pending.
Rajeev: Data I/O Security provisioning (slides circulated separately)
AP: Need to have a follow up task on this. This is just a prelude to what
the TF teams need to do in this area.
Rajeev: We can talk about the provisioning usecases next time.
Joakim: OP-TEE
Pending actions for creating branches for TF gerrit. Not done but have a
clear idea after talking to Dan
Linking TF.org to OP-TEE.org done one way. Plan to fix the other way with a
sit down with Web Admin at Connect.
Security sessions at Connect http://bit.ly/san19swg They will be added to
the public schedule (WIP)
Linaro has PoR (Plan of Record) process to say what work is done. Too early
to say what this will mean but things that are expected to continue:
- Keymaster work. Will look at new features in keymaster4.
- Prototyping work on Armv8 virtualisation.
- PKCS11.
- Widevine work
DH: Expecting that a lot of work will be followed up at Connect.
AP: When will incident handling be finalised?
DH: Not received any comments for a while. Also need steps to make it
active. Which projects will use it? Can spend some time to nail it down at
Connect. Then look to make it active.
--
[image: Linaro] <http://www.linaro.org/>
*Bill Fletcher* | *Field Engineering*
T: +44 7833 498336 <+44+7833+498336>
bill.fletcher(a)linaro.org | Skype: billfletcher2020
Hi All,
Any agenda items? We have following at present:
* Update on Twin CPU enablement work in TF-M (Chris Brand, Cypress)
* Secure provisioning discussion (Data I/O)
Thanks,
Abhishek
This screencast goes through the process I used to manage a CVE as part of
being the CNA for the Zephyr project. Not all of the links will be
accessible, but this should give a rough idea of the kind of work involved
in being a CNA.
https://www.youtube.com/watch?v=PksNzJXVDDA
David
Attendees
AbhishekP - Arm
DanH - Arm
DavidB - Linaro
MarkG - TI
JoakimB - Linaro OP-TEE
ChristianD - Cypress
JuliusW - Google
KumarG - Linaro LITE
KevinT - Linaro LITE
BillF - Linaro Community Projects
Agenda
OP-TEE
How to add more maintainers
AOB
Notes:
OP-TEE (Joakim’s slides)
BF: OP-TEE now visible via trustedfirmware.org
DH: No links to code etc
BF: Yes, just a first step that we can reference in any press release/blog
post. It links back to the main material at op-tee.org
JB: Have cleaned up op-tee.org content and not a big job to move it to
trustedfirmware.org
JB: Certifications. Should now revisit. However - there are many - need to
figure out what to spend the money on.
CD: Don’t certify in a vacuum
JB: Yes - video, payment ...
DH: … common criteria, safety. Generally need to certify a product, but
helps if know what you’re aiming for.
JB: Previously aimed at GC test suite that benefits everyone.
DB: FIPS certification
AP: At Arm have often focussed on ‘certifiable’ rather than certified.
JB: Sounds sane
AP: A lot of certifications have some common stuff - e.g. basic MISRA, some
threat model, lifecycle.
JB: If you clone the git repo you’ll get a test suite - xtest. You will not
get anything from GlobalPlatform. You can include it but you have to be a
member or buy it. It’s $6000 and includes support for 2 years. In Linaro we
have relied on member’s access to use the test suite.
DH: Code audits are good but take a hit - need to have all requirements in
place first like incident handling and lifecycle. They are expensive.
DH: For vulnerability reporting, have discussed increasing embargo period &
especially sensitive stakeholders.
DB: Zephyr is now a CNA. Organisation has to be a CNA but in the scope of
particular project(s). We’re receiving CVEs for the Zephyr project. It
might make sense for TF to become one.
DH: Process supposed to use for OSS doesn’t seem to work at all.
DB: End up going to the CNA of last resort. Much more responsive to CNAs
than random projects.
JB: tf.org/security should go to the various security centres and this
policy that we’re trying to approve.
Action DH to give BF an outline of what should be on the security front page
JB: Any interest on TF TSC that I present the plan for the coming cycle?
Action: JB to check with Mark Orvek if ok to share the OP-TEE information
from the project heathcheck.
CD: Generally take same approach as TF-A and TF-M. Share the information
but TF TSC not to be a bottleneck and have to ‘approve’. If there’s a
specific issue can discuss it at TSC.
DH: For the fork, we’d be trying to keep up with op-tee master and submit
back through the op-tee process. Don’t want to run on a branch for the long
term.
DH: Encrypted TEEs. Has always been a provision for encrypted TA’s.
Architecture allows for it but have had no strong pull for implementing it.
JB: Tricky part is key management
DH: May be a requirement on TF-A to help here.
JB: Haven’t really planned on this but seeing requirements. No requirements
from PSA?
DH: no - the requirements are on authentication, not encryption.
DH: (Next steps) Expand the list of acceptable licenses.
AP: (Documenting answers and decisions) Both TF projects are using
Phabricator.
Action: JB to contact Ben and try out the Phabricator sandbox.
DH: Anything holding back to setup an op-tee project in gerrit?
JB: Have an action to talk to Ben about setting that up
Maintainers
AP: Looking at ways to expand maintainers list since have gaps during
vacation period
JB: Where is the list?
AP: Keep the maintainer list in gerrit
AP: Ask other members to talk about non-confidential items. If there are
external companies - maintainers should be able to invite them to attend.
Action: BF to add link to review.trustedfirmware.org to Nav bar
DB: If I go to developer.trustedfirmware.org and click on
https://developer.trustedfirmware.org/project/ only see TF-A.
CD: Seems that project takes the first query
https://developer.trustedfirmware.org/project/query/edit/. Can an
administrator change the order of the queries?
Action: Move the usability discussion to the mailing list since there are
people actively working on Phabricator.
Attendance:
DH: (In response to KT) anyone should be able to join as long as we know
who they are from a member company. When it comes to voting that’s specific
to reps.
AP: If someone additional invited announce it at the start of the meeting.
Date for the next meeting?
AP: 12th Sept.
--
[image: Linaro] <http://www.linaro.org/>
*Bill Fletcher* | *Field Engineering*
T: +44 7833 498336 <+44+7833+498336>
bill.fletcher(a)linaro.org | Skype: billfletcher2020
Hi Joakim
Thanks for reviewing. Some further comments below.
> From: Joakim Bech <joakim.bech(a)linaro.org>
> Sent: 11 July 2019 13:11
> To: Dan Handley <Dan.Handley(a)arm.com>
> Cc: tsc(a)lists.trustedfirmware.org
> Subject: Re: [TF-TSC] tf.org security incident handling process (v0.3)
>
> Hi Dan and TF reps,
>
> Thanks for putting this together Dan. I like it and it's pretty short and
> concise. Nothing big from me, but please find a few comments from me inline
> below.
>
>> On Wed, 10 Jul 2019 at 18:35, Dan Handley via TSC
>> <mailto:tsc@lists.trustedfirmware.org> wrote:
>> Hi TF TSC
>>
>> This is a v0.3 update to the proposed http://tf.org security incident
>> handling process, which I sent previously, incorporating the comments I've
>> had since then.
>>
<snip>
>>
>> If you would like replies to be encrypted, please provide your public key.
>> Please note the Trusted Firmware security team cannot guarantee that
>> encrypted information will remain encrypted when shared with trusted third
>> parties.
>>
>> [DH: Is this acceptable? It allows reporters to use encryption without adding
>> too much admin burden on the security team. The alternative is to force
>> everyone receiving embargoed information to provide an encryption key and
>> decrypt/re-encrypt as information is passed around. I think this adds too
>> much overhead without significant security benefit.]
> [JB: I do think this is the right level of dealing with this. The
> communication with the one reporting the issue can (optionally) be encrypted,
> but for sharing between members of the security team I think it's easier to
> use things like LDAP protections, Google docs, GitHub private security
> advisories (https://help.github.com/en/articles/collaborating-in-a-temporary-
> private-fork-to-resolve-a-security-vulnerability) etc.]
>
I'm glad we're in agreement. I hadn't seen that GitHub security advisory support before - thanks!
<snip>
>> 3. After the primary embargo period, the fix and relevant vulnerability
>> information are shared with registered Trusted Stakeholders (see below
>> section). Fix release may be deferred further if a Trusted Stakeholder
>> requests it within 1 working day (Monday to Friday) of being notified,
> [JB: One day is not much time, there is a chance that people on the receiving
> end misses this for both good and bad reasons. However, I don't know how many
> days that would be sufficient. In the end these kind of things require some
> discipline and extra efforts from both sides.]
>
I think you're right this is a bit too aggressive. The window for requesting the primary embargo period is extremely short because we expect ESS security teams to operate 24/7 and we want to minimise the delay in proceeding to the next stage when ESSes are unaffected. But Trusted Stakeholders may need more time. We don't want to unnecessarily delay release of fixes but increasing this window a bit is unlikely to cause a problem in practice: If there is no primary embargo period it's likely we'll need at least a few days to prepare a fix anyway; if there is a primary embargo period, it's likely we'll need a secondary embargo period as well. How about making this window 3 working days?
<snip>
>> [DH: Note, this aggressive release of security fixes is aligned with the
>> kernel process. The existing TF-A process allows for early release of fixes,
>> which we generally do in practice, but that process doesn't really specify a
>> fix embargo period. However it does specify a 4 week embargo on the
>> subsequent security advisory. Also note that OP-TEE's fix embargo period is
>> 90 days, which is aligned with Google's policy.]
> [JB: Right, our initial OP-TEE embargo period was much shorter, but after
> getting feedback from our members it was clear that they preferred a longer
> embargo, which was the reason we went back to 90 days. Did we end up asking
> other people? TF members? Companies that we know are using TF-A/M?]
Sorry, I haven't sought any wider feedback. This is purely based on the Google and OP-TEE policies, which I (and I think TF-A partners would) find reasonable. Given that the fixes are made much earlier, I don't see anyone objecting to this longer advisory embargo, except perhaps some reporters.
>> 4. After the fix is released, details of the security vulnerability are
>> consolidated into a security advisory. This includes a CVE number and the
>> security team will request one if not already done by the reporter. It also
>> includes credit to the reporter unless they indicate otherwise. Drafts of the
>> security advisory are circulated with the reporter, ESSes and Trusted
>> Stakeholders as they become available.
> [JB: Do we want to have our own numbering schema also? If we believe _all_
> issues will get a CVE number then it's not needed. But if there are issues
> that for whatever reasons wouldn't get a CVE, then it's quite useful to have
> some internal numbering system. Out of experience, I know that it can become
> quite messy if you get a report containing lots of potential security issues.
> Having an internal number to use in commits etc has been proven to be quite
> useful.]
>
Yes, I do expect to have our own numbering scheme for the reasons you state. I thought this could be covered by a supplementary internal process, which we could create after this external process is approved. Let me know if you think we should say something here instead.
>> 5. 90 days after the vulnerability was reported, the security advisory is
>> made public at https://www.trustedfirmware.org/. This 90 day window is the
>> public embargo period.
>>
>> [DH: This public embargo period aligns with Google and OP-TEE processes,
>> although this proposal releases fixes earlier.]
>>
>> In exceptionally rare cases, the above disclosure plan may be extended in
>> consultation with the reporter, ESSes and Trusted Stakeholders, for example
>> if it is very difficult to develop or deploy a fix, or wider industry
>> consultation is needed.
>>
>> [DH: I'm accommodating for the Spectre/Meltdown case here]
>>
> [JB: So, is it fair to write the complete timeline as Fast case
> | Report given to TF: <X days> | <X days + 1>: first embargo | <+ 1
> | day>: second embargo | <+ 90>: public security advisory |
> i.e "X days + 1 + 1 + 90 = X days + 92"
>
> "Worst" case (mentioned in your attached PDF)
> | Report given to TF: <X days> | <X days + 14>: first embargo | <+ 14
> | day>: second embargo | <+ 90>: public security advisory |
> i.e "X days + 14 + 14 + 90" = X days + 118
>
> Or are the dates running in parallel so to say? Example: public advisory is
> always X days + 90?]
>
The latter! It should always be X days + 90. The above says "90 days after the vulnerability was reported". Let me know if I can make this clearer somehow.
<snip>
>> Note, the security team reserves the right to deny registration or revoke
>> membership to the Trusted Stakeholders list, for example if it has concerns
>> about the confidentiality of embargoed information.
> [JB: Only stakeholders list? What about ESS list?]
>
OK, I'll include that too.
>> [DH: Note, I've not included severity scoring in this proposal, as I think
>> the only value of a score is helping to determine whether a bug is a security
>> vulnerability or not, which in the end has a subjective element. I'm open to
>> the idea of adding this to the process but I'd prefer it to be optional and
>> aligned with CVSSv3 as used by CVE.]
> [JB: Agree and regarding the process I'm quite open to have a look at CVSSv3.
> The current OP-TEE process is better than the first one, but it's still a bit
> rough around the edges. If CVSSv3 works for TF-A/M, then I'll probably also
> work for OP-TEE. Also, something that I've been missing when doing work like
> this is an internal process also. But that's definitely out of scope for this
> discussion.]
>
OK but the process currently doesn't say anything about scoring. I guess we can look at CVSv3 later if there's a need.
I agree we will need internal process documentation as well but that can be worked through later. I can ask the current TF-A security team to help with this.
Regards
Dan.
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.
