Security & Crypto FT Meeting Minutes 2026 #2839

qor-lb · 2026-04-27T09:57:38Z

qor-lb
Apr 27, 2026
Maintainer

Security Feature Team (FT) Overview

👥 Leadership & Ownership

IG Lead: @sunildevda
Proxy: @andilar

Code Owners

(Formal process ongoing)

Company	Contact	GitHub Handle
ETAS	Athul Mallappallil	@ChansAlive
Valeo	Shorouk Ramzy	@ShoroukRamzy
IAV	Andre Larberg	@andilar
Qorix	Volker Haeussler	@PandaeDo
Accenture	Markus Schu	@masc2023

💬 Communication

Slack Channel: #C0B0F1J914Z
FT Meetings: Wednesdays, 10:00 - 11:00 AM CET/CEST.
- The Zoom meeting link can be found in the SDV Community Calendar.

💻 Development Resources

Main Repository: eclipse-score/inc_security_crypto
GitHub Project: SEC - Security FT (view)
Feature Request: score/issues/905
Pitch Slides & Minutes: discussions/2818

📚 General S-CORE Resources

sunildevda · 2026-05-05T08:04:10Z

sunildevda
May 5, 2026
Collaborator

06-May-26, 10-11 o'clock

Agenda:

[Organizational topic] Check participants
[Organizational topic] Additional meetings needed?
- We will have currently 3 meetings 06-May-26, 13-May-26 and 20-May-26 before the deadline for consensus 24-May-26. Do we need two more meetings on Monday 11-May-26 and Monday 18-May-26. Note: there are quite a few holidays coming up in Germany this month.
[Technical deep dive] How each company views the pitch proposal and what is the solution considering the different pitches?

Participants:
@mina-hamdi (Valeo)
mena dawood (Valeo)
Khalid Ramadan (Valeo)
Islam Abobakr (Valeo)
mbejijou-dev (Valeo)
omar EWEDA (Valeo)
@PandaeDo (Qorix)
@andilar -> Andre Larberg (IAV)
Werner Schreiber (Schaeffler)
Laszlo Marton (BMW)
Daniel Krefft (BMW)
@tina Sayarmoafi (Polito)
@masc2023 (Accenture)
@tizava (ETAS)
@ChansAlive (ETAS)
@OliverHeilwagen (ETAS)
@sunildevda (ETAS)

Minutes:

Already plan for additional meeting. Create meeting request for Monday 11 May from 10AM to 11AM CET (and if needed another for Monday 18 May). R @sunildevda

Opinions about different pitches:
Schaffler (Werner Schreiber):

Motivation is to have a solution that works in NxP HSE S32G hardware.
ETAS solution fits well.
Valeo has "security as service" which will have daemon and this will be then comparable to ETAS crypto daemon approach. but this is not part of OSS.
Would be good to have Rust API (could be taken up in future)

BMW (Daniel Krefft & Laszlo Marton):

ETAS solution seems to be similar to current in house solution.
Autosar API wrappers are important. Architecture should be extensible to include the autosar apis. and this can be outside SCORE.
Key store is a different topic. and needs to be aligned with the idea what BMW presented in the pitch.

Valeo (Mina Hamdi & Mena Dawood):

Build on view from Schaffler.
Chance to integrate different solutions into one solution.
Which API to be used at higher level? ETAS APIs are SCORE APIs not like PARSEC which is an open source standard.
PARSEC would be favored internally but ETAS approach is fine
Hardware drivers can be plugged in

IAV (Andre Larberg):

Wish different solutions can fit together. Super group of Crypto APIs.
Question from Schäffler: IAV firmware emulate the hardware in software

ETAS (Athul, Oliver, Sunil)

Create IAV Provider to demo direct usage of IAV Primula
Swap SoftHSMv2 with Valeo Cryptoki
Align OpenSSL version which is used
Local Provider
- Question: What operations shall be supported
- Proposal: Keyless + Ephemeral key + Public key operations
API: Shall be shaped / refined in OSS S-Core
Details in attached pictures below.

Other points:

Do we need to have new SCORE API or we use industry standards APIs like PKCS11,...?

BMW will check the proposal that ETAS pitch has and see if it fits their use case.
APIs proposed by ETAS is extensible. And can be changed and made better on feedbacks here.
PKCS11 does not support Certificate based functionalities, so we will anyway have to find a solution that is uniform and also addresses these use cases.

First level consensus about the unified solution presented by ETAS:

In high level, the approach presented by ETAS looks ok. and we need to deep dive this and see if this we go ahead with this approach.
Voting on next meeting on Monday.

LG solution not considered as there is no PR or slides available. If these needs to be addressed then may be a feature request in future to be taken. but right now its not considered.

Unified solution slides:

0 replies

sunildevda · 2026-05-08T07:39:11Z

sunildevda
May 8, 2026
Collaborator

11-May-26, 10-11 o'clock

Agenda:

[Organizational topic] Check participants
Voting and thoughts for the last meetings proposal
Next steps

Participants:
@mina-hamdi (Valeo)
mena dawood (Valeo)
Khalid Ramadan (Valeo)
Alaa Mahdy (Valeo)
Ahmed TAREK-RAMADAN (valeo)
Werner Schreiber (Schaeffler)
LEnard Rhenisch (IAV)
Islam Abobakr (Valeo)
Laszlo Marton (BMW)
@tina Sayarmoafi (Polito)
Seongwok Min (LGE)
se-lo Sebastian (ETAS)
@ChansAlive (ETAS)
@OliverHeilwagen (ETAS)
@sunildevda (ETAS)
@tizava (ETAS)

Minutes:
Valeo (Mina)

already tried a quick check of PKCS11 integration into ETAS crypto and looks like there are no major integration issues.
IAV FSM is currently not planned to be integrated into the SCORE.
Schaeffler (Werner Schreiber):
- Where to integrate the NxP HSE crypto provider? to keep under the crypto security incubation repo.
We have a consensus to go ahead with the current proposal and present to the architecture community (with next steps described below)

Next steps:

Formal steps for consensus closure:

Highlight the different solutions with color code and may be combine the different pitch slides and present this to architecture board. R. Sunil
Present in architecture board. Next Monday 18 May 2026. Mina, Sunil, ...
Code owners - Open point, how many per company? how is it organized?
Move from SCORE Crypto Incubation (inc_security_crypto) to SCORE Crypto → check with Lars
Is there any expectation on the roadmap for 2026?

Roadmap on the list of changes that should come by which SCORE release till end of 2026
ETAS:

Create a PR to merge the changes (Copy right update from ETAS → SCORE)
To improve the architectural changes:
- Migrate gRPC to mw:com (lola) (little complex. needs timeout implementation. needs some work to be done)
- Concurrency / Thread safety
- Performance improvement
- Local provider concept (Has impact on overall architecture)
Configuration
Quality (code coverage, ITF based tests, requirements, user documentation,...)

IAV:

To integrate IAV Primula for SCORE → migrate to SCORE set up example mw:log, bazel, baselibs, copyright updated to SCORE...
To develop the IAV Primula as crypto provider in C++
Also, update the API to expose these functionalities at SCORE API level. This basically means to update the following contexts: Signature context (to support CRYSTALS-Dilithium 2/3/5, Falcon 512/1024, SPHINCS+ 128/192/256) , Key exchange (to support CRYSTALS-Kyber 512/768/1024 and HQC 128/192/256)
- Which all you plan to implement especially we see that in the presentation for FALCON we see the timing is unacceptable for automotive? -Y yes it could be suitable for secure boot. all 5 algorithms will be part of SCORE solution.
Timing measurement (after mw:com (lola)) to compare the additional delay that is introduced due to Lib Daemon communication v/s the measurements shown in pitch slides. We could start with gRPC to get the basic infrastructure and can be doing in parallel with existing solution.
Quality artifacts for the crypto provider (as expected by SCORE tools and process)

Valeo:

To integrate PKCS11 as crypto provider → migrate to SCORE set up example mw:log, bazel, baselibs, copyright updated to SCORE ...
To have only one version of OpenSSL on the target
Quality artifacts for the crypto provider (as expected by SCORE tools and process)

Schaffler:

Fork the ETAS SCORE Crypto / SCORE Crypto incubation repo. Try out implementing one crypto algorithm on HSE and see how it goes.
Fork the Valeo solution and also try the same thing. this currently is in Rust.
Try all the three different possibility of integrating the HSE Crypto providers (as shown in the picture) and see how it goes.
To do performance benchmark on actual hardware and also compare against software provider (ex. PKCS11 → openSSL) -> far future. current focus is on above steps.

BMW

PoC with ETAS code, deploy on the target. migrate the current application from internal solution to ETAS SCORE solution. This will also include API evaluation.
To do performance benchmark on actual hardware and also compare against software provider (ex. PKCS11 → openSSL) -> far future.

Open points/other points:

Integration point for different Crypto providers? either below SCORE crypto provider or PKCS11 or openSSL -> document this as one of the design decision.
APIs shall be reviewed and changed/improved where necessary.

Come prepared with the propose code owners from each company (if needed) by our next meeting on coming Wednesday.
Rough timelines for each of these steps (for roadmap perpetration)

Rough sketch of different contributions from different companies:

0 replies

sunildevda · 2026-05-11T13:55:50Z

sunildevda
May 11, 2026
Collaborator

13-May-26, 10-11 o'clock

Agenda:

[Organizational topic] Check participants
Review of the slides with unified solution to present to architecture community
Code owners
Time lines for next steps
- SCORE milestone releases for 2026: https://github.com/eclipse-score/score/milestones
- Security FT: SEC - Security FT
- Security for SCORE 0.8 release (13.Jul.2026):
- Security for SCORE 0.9 release (07.Sep.2026): Security for S-CORE Release v0.9 #2888
- Security for SCORE 1.0 release (02.Nov.2026):

Participants:
Seongwok Min (LGE)
@tizava (ETAS)
se-lo Sebastian (ETAS)
@mina-hamdi (Valeo)
Volder Haeussler (Qorix)
Werner Schreiber (Schaeffler)
@oeweda
basheerFZ
Laszlo Marton (BMW)
@ChansAlive (ETAS)
@OliverHeilwagen (ETAS)
@sunildevda (ETAS)
Ahmed Rushdy (valeo)
Khalid Ramadan (Valeo)
@GuruprasadBhatL (ETAS)
Islam Abobakr (Valeo)

Minutes:

Reviewed the unified solution slides (below) and will be presented in architecture community on Monday 18.May 2026
Code owners: ETAS (Athul - @ChansAlive, @OliverHeilwagen), Valeo ( @oeweda ), Volker Haeussler (Qorix), Markus shu
Code owners skills to be checked example as shown here: https://eclipse-score.github.io/score/main/modules/orchestrator/docs/safety_mgt/module_codeowners.html. There will be separate invite for this. R. Volker Haeussler
Open point: Who is/are the code owners from IAV?
Rough plan for the next steps:

Feature/topic	Contents	Date	Task owner	SCORE release version -
Create a PR to merge the changes	Copy right update from ETAS → SCORE	22.May.2026	ETAS	v0.8
Integrate GitHub workflows	Tests on Linux only (take over the GitHub workflows from other existing repos like SOME/IP or LCM)	08.June.2026	ETAS	v0.8
Data plane changes		08.June.2026	ETAS	v0.8
Step 1: Migrate gRPC to mw:com (lola) PoC with google test	Move to lola PoC with one isolated googletest. Crypto api to daemon is still in gRPC. With multi client. No timeout. No access control	08.June.2026	ETAS	v0.8
Step 2: Migrate gRPC to mw:com (lola)	Migrate Crypto API to deamon to lola. No timeout. No access control.	20.July.2026	ETAS	v0.9
Architecture documentation for concurrency / Thread safety	Analysis to make the existing architecture is thread safe (concurrency works as expected). Implementation is not in scope. Will be planned based on the analysis outcome	06.July.2026	ETAS	v0.9
Test on QNX8 (local tests)	Get the integration tests running on QNX8 (currently tests are running on Linux only). Integration tests depends on the ITF set up and not sure when ITF will be stable in SCORE.	20.July.2026	ETAS	v0.9
Analysis for performance improvement	Tests and measurements to understand which code parts take what parts	03.Aug2026	ETAS	v0.9
Local provider concept	Has impact on overall architecture. Only concept and possibly some PoC code.	31.Aug.2026	ETAS	v0.9
Movement from incubation repo to crypto repo	Expected maturity level? We can do it immediately. After the feature request is approved and closed. Integration to reference integration repo after more maturity (quality artifacts)	?		v0.9
Changes in lola (dependency to be implemented in lola for Crypto use case)	Config less approach For access control -> get client UIDs	Expected end of 2026
Integrate IAV Primula to SCORE	migrate to SCORE set up example mw:log, bazel, baselibs, copyright updated to SCORE.. Open point: Will it be a separate repo?		IAV
Implement the IAV Primula crypto provider in C++			IAV
Implement Signature context and Key exchange	update the API to expose these functionalities at SCORE API level. This basically means to update the following contexts: Signature context (to support CRYSTALS-Dilithium 2/3/5, Falcon 512/1024, SPHINCS+ 128/192/256) , Key exchange (to support CRYSTALS-Kyber 512/768/1024 and HQC 128/192/256)		IAV?
Integrate PKCS11 (Cryptoki) to SCORE	migrate to SCORE set up example mw:log, bazel, baselibs, copyright updated to SCORE..	To be given in next meeting	Valeo
Have only one version of OpenSSL on target		To be given in next meeting	Valeo
Fork ETAS and Valeo solution and try integration of HSE	This is just to get familiar, nothing will be checked in SCORE. Or? Already started with Option 1. OpenSSL calls are being migrated to HSE calls. Code will be merged after the first step is completed by ETAS.	End of June	Schaffler
PoC for integrating HSE crypto provider for all three integration points		To be taken up later after step 1	Schaffler
PoC with ETAS code, deploy on the target.	migrate the current application from internal solution to ETAS SCORE solution. This will also include API evaluation.	End of June	BMW
Timeout support	in the new approach this can be done in crypto only.
Configuration		2027
Key management functionalities like import key, export key, KDF,...		2027
Certificate management and services		2027
Crypto features like Encryption/Decryption, Signature generation/verification, ..		2027
Quality (code coverage, ITF based tests, requirements, user documentation,...)		2027

Unified solution slides:

0 replies

sunildevda · 2026-05-18T12:50:44Z

sunildevda
May 18, 2026
Collaborator

20-May-26, 10-11 o'clock

Agenda:

[Organizational topic] Check participants
Updates from Architecture presentation:
- Meeting minutes: https://github.com/orgs/eclipse-score/discussions/2457?sort=new#discussioncomment-16957084
- Went smoothly. no main points raised.
- Code owners should also be committer. to check this internally in each company.
- Code owners: ETAS: Athul - @ChansAlive, Valeo: @oeweda, Qorix: @PandaeDo (Volker Haeussler), Accenture: @masc2023 (Markus shu), IAV: @andilar (Andre Larberg)
Planning board: SEC - Security FT (view)
- Epics and tasks for ETAS contributions created for next steps till milestone release 0.9
- Code freeze is two weeks before the milestone release date.
- High level target is to get the Crypto to be part of milestone release 0.9 -> this means Crypto shall be integratable in the reference integration repo.
- Timelines for Valeo, Schaffler contributions.
Hash is also part of Baselibs and this integrates OpenSSL. Checking with Baselibs team about the use cases: https://github.com/orgs/eclipse-score/discussions/2390?sort=new#discussioncomment-16903198. Target is to replace the hash from baselibs and to be offered as part of Crypto.

Participants:

Meeting minutes:

Committer process to be checked and followed for each committer in the company.
- Role descriptions: https://eclipse-score.github.io/process_description/main/roles/index.html (process)
- Detailed version: https://gist.github.com/AlexanderLanin/332d7b258d9b23c09408fa6ad0df5630
- Committer training: https://www.eclipse.org/projects/training/
- Found in: https://eclipse-score.github.io/score/main/platform_management_plan/security_management.html#securi…
- CODEOWNERS example file: https://github.com/eclipse-score/baselibs/blob/main/.github/CODEOWNERS
Precondition from incubation repo to proper repo needs some minimum documentation like component requirements, .. There is a template and we need to fulfill all the conditions for this. https://github.com/eclipse-score/module_template. This is planned in the issue: Initial module documentation inc_security_crypto#17
For planning remove the rename from Integrate GitHub workflows inc_security_crypto#8 and move it to a different ticket.
. Mina, Werner and IAV will create the Epics and Tasks for Valeo, Schaffler and IAV contributions. Process work instructions for planning:
https://eclipse-score.github.io/score/main/platform_management_plan/project_management.html#planning-tracking
Valeo the target is 8 June 2026 for both Cryptoki integration and migrate to one openssl version.
Milestones for Schaffler
Step 1:
PoC for options 1,2,3 of NXP HSE integration
select one use case each (e.g., single shot hashing) and get it running on NXP eval board
investiage implementation alternatives (exisiting within each option)
Due date: end of June

Step 2:

define implementation concept and align with Security&Crypto team
aspects like legal and performance to be considered
make implementation planning considering inputs from Security&Crypto team
Due date: end of July

Step 3:

Implementation and testing phase, alignec to the overall timeline
Hash movement from Baselibs need to also check about the quality expectation, lib or lib+daemon approach, maturity expectation and so on. Sunil and Oliver H are in discussion with Andre Babanin and will update here again later.

0 replies

sunildevda · 2026-05-27T07:31:01Z

sunildevda
May 27, 2026
Collaborator

27-May-26, 10-11 o'clock

Agenda:

[Organizational topic] Check participants
Pinned message: https://github.com/orgs/eclipse-score/discussions/2839?sort=new#discussion-9956819.
Review of PRs till Code owner process is completed
ETAS task status:
HSE integration: Demo?
Status for other tasks

Participants:

Minutes:
Agenda:

[Organizational topic] Check participants
Pinned message: https://github.com/orgs/eclipse-score/discussions/2839?sort=new#discussion-9956819.
- Proxy: Andre
Review of PRs till Code owner process is completed
- Review can be done by anyone in the team but merge can be done only by committers (Ex. Volker and Markus)
- Can being a committer in other Eclipse projects speed up or gets a committer status in the SCORE project as well? Andre (IAV) already is a committer. Check once with Arvid. R. Sunil
- Request to also include Athul (@ChansAlive ) as one of the reviewer.
ETAS task status:
- First PR merged: Merge ETAS PR inc_security_crypto#7
- Git workflow activation ongoing: Integrate GitHub workflows inc_security_crypto#8
HSE integration: Demo
- Running on HSE Hardware
- Option1: SCORE provider with HSE. PKCS11
- Option 2: HSE library is added dynamically as PKCS11 provider.
- Option 1 is faster when compared to option 2.
- AES128 bit encryption was also tried. compared OpenSSL against HSE. HSE (about 56ms) was much faster (softHSM is about 250ms). Getting this needed some key related activities.
- Integration was quite smooth.
- May be there will be have both Option 1 and Option 2 together.
- Attached log has more details. HSE_vs_SW.txt
- Changes cannot be part of SCORE due to license incompatibility. But if the library is loaded dynamically then there is no license incompatibility.
- Providers can decide during initialization if the library has to be static or dynamic loading/linking.
- Consider the dynamic loading in configuration structure. This makes integration for proprietary providers faster.
- As part of this POC Werner will also summarize the configuration parameters that is needed to set up HSE, this will then be one of the inputs for the configuration of the Crypto.
- Build error being faced due to missing tool dependencies. Changes to solve this is in the PR Add rust toolchain to fix rustfmt crosscompilation error inc_security_crypto#37
IAV
- Planning Epic created. Task distribution will be done in coming days.
BMW
- Certificate and signature verification are the current main use case that is currently needed but they are missing in the current SCORE crypto
- However, there are APIs defined here: https://github.com/eclipse-score/inc_security_crypto/tree/main/score/mw/crypto/api/future/certificate and https://github.com/eclipse-score/inc_security_crypto/tree/main/score/mw/crypto/api/future/contexts/src for signature and certificate. this could be used as a reference and inputs on what is missing.
Valeo
- Holidays in Egypt. Status to be checked next time.

0 replies

schreibwsag · 2026-05-27T10:21:54Z

schreibwsag
May 27, 2026

Here you can find my first results working on NXP HSE for score_provider and pkcs11_provider:

HSE_vs_SW.txt

0 replies

andilar · 2026-06-03T07:40:19Z

andilar
Jun 3, 2026
Collaborator

3rd of June 10:00 - 11:00

Agenda & Minutes

[Organizational topic] Check participants (@sunildevda is not joining today, @andilar is taking over the moderation)

General status of tasks
1. Schaeffler is preparing a running PKCS11 provider example, initializing takes about 25s for initialization. Valeo is providing 1on1 help for this topic. The delay is notable.

The test script can be shared by Werner Schreiber (Schaeffler), @schreibwsag to Valeo, see comment above. 2. Valeo created more tasks, already in progress of some. (th of June is a milestone, license headers have to be updated. 3. IAV still looking into licenses and also providing the latest PQC libryr, there will be an update. 4. ETAS mentions the importance of cross compilation for different platforms and build variants. We can probably take over matrix build from base libs or others. e.g. --> https://github.com/eclipse-score/baselibs/blob/main/.github/workflows/build_linux.yml#L31C1-L47C72 We need some tickets for this.

Update of hashing (SHA1) support in Baselibs.
a. Aligned with the baselibs team and we agreed that we can move SHA implementation to Crypto away from OpenSSL. Basic hashes will stay in baselibs, e.g. CRC and others
b. Step-wise migration transition:
1. Inform in Baselib users that a migration is planned.
2. Support Hashing algorithms SHA256, SHA384, SHA512 in security_crypto.
3. Config management and other known users migrate from Baselib APIs to security_crypto APIs.
4. Remove the now legacy algorithms from Baselib. Update documentation that all cryptographic hashes are part of security_crypto. and in the same time we inform that SHA1 is depreciated.
5. Time line is open, requirements check have to be done as well, so no mismatch is happening, ASIL context support is necessary
Discussion about gRPC -> mw:com (lola migration), some limitations have been detected. Team will be discussing further today (2nd of June) with the COM team as well and depending on the discussion outcome. Any updates on this?
a. one concern is the COM configuration for users, dependencies etc
b. long term goal is to choose the best abstraction level
c. existing POC can be expected to be public, still some things to clarify

Participants

0 replies

sunildevda · 2026-06-09T16:42:34Z

sunildevda
Jun 9, 2026
Collaborator

10-Jun-26, 10-11 o'clock

Agenda:

[Organizational topic] Check participants
Task status
S-CORE folder structure to understand where to integrate IAV Primula
Hashing support for PQC: SHA3-224, SHA3-256, SHA3-384, SHA3-512, SHAKE128 and maybe SHAKE256.
PKCS11 integration timing issue

Participants:

Minutes:

PKCS11 integration timing issue: Valeo tried to reproduce it and did not see high timing. timing seen was 0.2s (compared to 21s as seen by Werner). Library size was about 4MB (compared to 16MB library size seen by Werner). Could be possible due to compiler optimization. Valeo would share the library via slack. Command to build -c opt.
PKCS11 (Cryptoki) Integration with SCORE: Library is dynamically loaded. This also includes the changes to have only one openssl library in the target. mw:log is integrated. There were issues in integrating baselibs rust library. tool chain is very strict (0.69). Temporary workaround to not use SCORE rust tool chain. This will need to be cleaned up when we move to reference integration repo. Branch created. PR will be created soon. Reviewers: @ChansAlive , @PandaeDo / @masc2023, @schreibwsag , @OliverHeilwagen
PoC for Data plane · Issue #10 is ongoing and on track to be completed by iteration 22 (15 June to 28 June)
PoC for migration of gRPC to mw:com (lola) · Issue #11 exploring direct usage of message passing abstraction of lola (this is an component in mw:com). this is config less and can support/extended for timeout. but has limitations like inter VM communication cannot be done and so on. also, being checked is if we can only integrate message passing abstraction without integrating lola.
S-CORE folder structure to understand where to integrate IAV Primula: general folder structure for modules: https://eclipse-score.github.io/score/main/contribute/general/folder.html . IAV Primula is a sub component within Crypto (need not be separate repo) but it could be made public and used in isolation.

IAV crypto provider to be added as a folder under https://github.com/eclipse-score/inc_security_crypto/tree/main/score/crypto/daemon/provider/score_provider
IAV Primula library will be a separate repo. and then we need to follow the folder structure as explained here: https://eclipse-score.github.io/score/main/contribute/general/folder.html
SHA integration: currently the solution uses FSM and https://github.com/iavofficial/PQCleanAutomotive/blob/master/Sphincs/SphincsSha2_128fSimple/FsmSw_SphincsSha2_128fSimple_hash_sha2.c one option would be to integrate to openssl. but this will lead to cyclic dependency. We need to discuss how

Missing access rights to create task or assign tasks in SCORE. Could be due to missing names in the SCORE project. R. Sunil

2 replies

andilar Jun 10, 2026
Collaborator

From IAV side we have two topics:

we would like some experienced S-CORE contributer to give us an headstart for file and folder structure. We are not sure where things should go, that would be nice.
We need for PQC the SHA3 hashing functions, you know like: SHA3-224, SHA3-256, SHA3-384, SHA3-512, SHAKE128 and maybe SHAKE256. Does the "Crypto Library" provide us with this?

PandaeDo Jun 10, 2026
Collaborator

I can help on the first topic. Just invite me or contact me via slack.

General folder structure can be found here: https://eclipse-score.github.io/score/main/contribute/general/folder.html. Documentation is separated. For the modules as security_crypto is the best way to ensure the expectation would be to use/copy everything from
https://github.com/eclipse-score/module_template/tree/main/docs which is provided for that use case.

sunildevda · 2026-06-16T18:57:52Z

sunildevda
Jun 16, 2026
Collaborator

17-Jun-26, 10-11 o'clock

Agenda:

[Organizational topic] Check participants
(follow up) Updates regarding access rights - Sunil
Results of tests of Crypto Daemon on QNX - BMW
Updates about PKCS11 integration timing issue for NxP S32G hardware - Werner
Data plane changes (Integration of Data plane inc_security_crypto#10) - Guru
Folder structure for where to place crypto providers - Athul

Participants:

Minutes:

Updates regarding access rights

Resolved for Andre, Hamdi. Still issues with Werners account. resign the ECA and check.

Results of tests of Crypto Daemon on QNX - Ugesh, BMW

Crypto incubation repo was integrated into internal project
Changes had to be done in repo to get the basic build running including changes to include tool chains needed for Bazel build. Warnings are treated as error by default and this was disabled to get the build running + additional changes for debugging. Some of these changes are temporary due to gRPC being used and will no longer be needed when migrated to lola.
Build using OpenSSL and SoftHSM as present in crypto incubation repo. Idea is to only get the build through. its a dummy library. actual use case is to use the PKCS11 crypto provider (cryptoKi) that will be integrated by Valeo.
Process were launched using execution manager and was done with security policy enforcement. This also included some of the abilities that are restricted or not to be used based on internal security requirement.
These changes will support anyone who is trying to get integrate the score crypto into the full fledged project.
Currently all these codes what were shown are internal and being checked internally if these can be published for reference for others.
Next step is to try with QNX8.
HMAC was tried and flashed in the actual ECU. HMAC demo application running on the actual hardware. SHA is also updated.
Improvements in SCORE Crypto:
1. Bug: if first provider is not available the daemon terminates. this fix is needed in SCORE incubation repo.
2. One small patch related to std type for QNX7 needed in std.
3. Add a configuration support to remove the crypto providers. layered architecture separation needed, so that we can only include what is needed. -> this is already present in the current PR from Valeo.
To consider Security policies during the development first. Access control and security policy is an overarching topic and we should have a separate discussion about this in coming days.

Review for Valeo CryptoKi integration PR

PR : https://github.com/eclipse-score/inc_security_crypto/pull/49/changes
PKCS11 should be able to work with any PKCS11 implementation.
One idea is to move all the crypto provider implementations to a separate repo "back-end" . Idea to be presented next week and discussed further.
We can then select the correct back-end to be used
Flexible to support different versions of PKCS ex. 2.4 or 3.2 version
Current version in Valeo PR is 2.4 and 3.0. 12 functions added in 3.0. Support for 3.2 is planned in the roadmap.
Hint for PR review: SoftHSM is not yet removed. this is configurable via environment variable.
Rebase has been done. continue with the review in PR itself.
Holiday for next 3 days in Egypt.

Points that could not be discussed in todays meeting to be taken up in next weeks meeting (4, 5 and 6)

0 replies

schreibwsag · 2026-06-17T04:56:35Z

schreibwsag
Jun 17, 2026

Regarding "PKCS11 integration timing issue: " from meeting June 10th:
ECB-AES128_libcryptoki_libsofthsm2_libpkcshse.txt
Please find attached a comparison libcryptoki (debug) vs libcryptoki (release) vs libsofthsm2 vs NXP libpkcshse.
Tests were done on NXP S32G3 (aarch64).

0 replies

sunildevda · 2026-06-17T09:15:51Z

sunildevda
Jun 17, 2026
Collaborator

24-Jun-26, 10-11 o'clock

Agenda:

[Organizational topic] Check participants
Updates about PKCS11 integration timing issue for NxP S32G hardware - @schreibwsag
Data plane changes (Integration of Data plane inc_security_crypto#10) -> delayed and will be discussed next time
Concept for back-end servers (including where to integrate IAV contribution) - @ChansAlive
ACL parser - @christianbe9

Participants:

Minutes:

Updates about PKCS11 integration timing issue for NxP S32G hardware - @schreibwsag
- CryptoKi: after using the correct library (_relase.so) the time reduced from 35s to 2s. It is possible to use both as static and dynamic loading. so far Valeo had tried for dynamic loading. Both mechanism of static and dynamic loading shall be supported by configuration. Valeo will work on this and see how the performance can be improved in coming days. But the timing is still high compared to libsofthsm and pkcs11 with actual hardware (timing values below)
- libsofthsm - 0.2s
- pkcs11 with actual hardware - 0.021s
- Dynamic loading vs dynamic linking: NxP HSE S32G cannot be made open source due to license issue. crypto provider can be built with standard PKCS11.h. actual library can be loaded using dlopen.
Concept for back-end servers (IAV integration)

We need to develop the IAV Primula Crypto provider. This is basically the glue code that will bridge between Crypto daemon and IAV Primula library. This could be in a sub folder here: https://github.com/eclipse-score/inc_security_crypto/tree/main/score/crypto/daemon/provider/score_provider
Where to keep the IAV Primula code? As a separate repo or directly in the inc_security_crypto repo?
this is the decision to be done. each of the option has some advantage and disadvantage. Having a separate repo has the complexity of dependency on OpenSSL for hashing algorithm support. Crypto also needs OpenSSL and depends on IAV Primula and IAV Primula inturn depends on OpenSSL.
We can go step by step. in first step we can integrate directly in the inc_security_crypto. and in later step it can be in separate repo. which will mean we have the possibility of standalone direct usage.
We can use label flags to switch off the targets (back-ends are drop-able). this brings the flexibility of swapping with different backends. Discussion could not be completed and to be continued next week.
IAV primula library itself can be integrated into the sub-folder https://github.com/eclipse-score/inc_security_crypto/tree/main/score/crypto/backend/IAV_Primula
CryptoKi is also moved to into the sub-folder https://github.com/eclipse-score/inc_security_crypto/tree/main/score/crypto/backend/CryptoKi in the current ongoing PR.

ACL parser - @christianbe9

We can have one parser for all ACL use cases like IPC, SOME/IP, Crypto
Has option for custom extensions under specifics to include custom implementations like tokens.
IPC is made via UID
SOME-IP could be IP based
Possible to split this into different files
Crypto ACL has uid + also the permissions and MAC abilities
Idea is to have a same config format by all ACL use cases
We can have some kind of library in Baselibs that will be used to write the contents
Main question is if we can unify and align on format. this is cross cutting topic and should be discussed in arch meeting
Idea definitely makes sense and should be discussed in arch meetings. Meeting [sdv-wg-SCORE] Architecture Community every Monday, June 1·2:00 – 3:00pm. Calendar https://eclipsesdv.org/get-involved/
Create a Decision record in SCORE and tag different teams for alignment. https://eclipse-score.github.io/score/main/design_decisions/index.html
@christianbe9 could you please share the .json file you had shown in the meeting?

3 replies

christianbe9 Jun 19, 2026
Collaborator

Not only for crypto -> Generic discussion on an ACL format & ACL Parser, so that we have 1 parser which is able to parse different ACLs:

IPC
SOME/IP
Crypto

As the ACL will be used by multiple components and is somewhat also the "interface"/"exchange format" between the enforcement points and the updater/installer/etc.

GuruprasadBhatL Jun 19, 2026
Collaborator

Regarding point 5, could you please clarify the exact scope of the "ACL format & parser"?
Specifically, is the parser intended to read:

    A configuration file defining application-level policies (e.g., for SOME/IP, Crypto)?

    A configuration file that specifies filesystem ACL permissions to be applied to objects?

    Or are we parsing/managing actual OS-level POSIX ACLs directly?

christianbe9 Jun 22, 2026
Collaborator

Sure; in the end I wanted to address your first and second point; not your 3rd point. Where as I would like to focus first on the first point, i.e. ACL config for SOME/IP, IPC & Crypto.

Concrete Example:

SOME/IP:
--> SOME/IP should be able to filter depending on the IP addresses, ServiceID, TLS required, etc. whether the service request or provision is valid
IPC:
--> During startup when the ServiceProvider applications are initialized and publish their service, they need to know which users (I.e. uids) are allowed to access the service to configure the permission of the service discovery file + shared memory objects accordingly -> ACL and according parser required
Crypto:
--> The cryptoDeamon somehow needs to know to grand which application (i.e. uid or policy - or both) access to which keys and according operations --> ACL as well required.

--> I will prepare an example for the session so we have a concrete basis to discuss on

sunildevda · 2026-06-30T08:20:45Z

sunildevda
Jun 30, 2026
Collaborator

01-July-26, 10-11 o'clock

Agenda:

[Organizational topic] Check participants
Update of module folder template: Include all templates for documentation inc_security_crypto#62 @PandaeDo
Data plane changes (Integration of Data plane inc_security_crypto#10) -> @GuruprasadBhatL
Status of other ongoing PRs

Participants:

Minutes:

Update of module folder template: Merge code of ETAS pitch inc_security_crypto#6

We will have three components: 1. Crypto, 2. CryptoKi, 3. IAV Primula
Under Crypto we will have as sub components.
Check if "mw" is needed and also move the contents under Crypto: https://github.com/qorix-group/inc_security_crypto/tree/main/score/mw/crypto/api
CryptoKi will adapt to this new place the current PR.
https://github.com/qorix-group/inc_security_crypto/tree/main/score/CryptoKi + take over the folder structure as created in the above PR -> Valeo
https://github.com/qorix-group/inc_security_crypto/tree/main/score/IAVPrimula + take over the folder structure as created in the above PR -> IAV
all third party software's will remain in the folder: https://github.com/qorix-group/inc_security_crypto/tree/main/third_party

Data plane changes (Integration of Data plane inc_security_crypto#10) -> @GuruprasadBhatL

PR will be created soon.
For control plane Lola will be used. For data plane message passing (unix domain socket, shared memory) will be need for the Crypto architecture need. What is used in this feature is shared memory from Baselibs. There were some discussions about shared memory would be moved to Com.
General the question is should we extend lola to include pipe memory (especially for inter VM communication) or shared memory baselibs.
Currently the idea is to move forward with Baselibs shared memory and in next step move to Com lola.
Follow up with the inter VM topic with Arch team. R. Sunil
Reviewers: Christian, Oliver, Markus/Volker

CryptoKi - Valeo

First PR:
- Optimization ongoing to solve initialization delay. temp improvement will be part of this PR.
- Will adapt to the folder change mentioned above
Next PR: There will be more optimization done.
Integrate 3.2 PKCS11 will be taken up in next step. Analysis for the scope of change is done but the change itself will be taken up in next PR.
Shorouk Ramzy will coordinate for Valeo going forward.

IAV Primula
- All changes will go directly to main.
- There is a naming convention on the branches in the process: https://eclipse-score.github.io/score/main/contribute/general/naming.html
JSON scheme update - Christian
- DR will be created soon. Request for review. At least with the focus on Crypto part. and then take it to the architecture round for the refinement for SOME/IP, IPC,....
- Reviewers: @ChansAlive , @GuruprasadBhatL
Should we have OpenSSL as front end APIs?
- Currently OpenSSL, PKCS11 and others are backend API
- Motivation for frontend API and Crypto architecture is also explained in the pitch slide here: [Contribution Proposal] Security ETAS #2220 (comment)
- The Crypto API is initial implementation. This can be further extended based on feedback.

0 replies

sunildevda · 2026-07-07T12:03:41Z

sunildevda
Jul 7, 2026
Collaborator

08-July-26, 10-11 o'clock

Agenda:

[Organizational topic] Check participants
Update of module folder template: Include all templates from module_templates to start documentation inc_security_crypto#72 - @PandaeDo merged
Testing on QNX8 is locally working. crypto: Add qnx test execution for test binaries (cc_test) inc_security_crypto#70 - @OliverHeilwagen
PR for the decision record of generic format for ACL created DR-003-ARCH-ACL-Concept: Generic Format for Access Control List #3058 - @christianbe9 -> to be taken up next week.
Status of other ongoing PRs
Elections of Carolina Pelka and Tim Kaiser for Primula started. Exception for election also in this case to have somebody who is really familiar with bigger contributions from companies. Please inform Committers in your companies that we can also apply this for other components if needed.

Participants:

Minutes:

Update of module folder template: Include all templates from module_templates to start documentation inc_security_crypto#72 - @PandaeDo merged
Testing on QNX8 is locally working. crypto: Add qnx test execution for test binaries (cc_test) inc_security_crypto#70 - @OliverHeilwagen
- One PR for otterdog change is pending.
- Module basel is updated. newer tool chain was added.
- qnx_unit_tests and images added. have to configure IFS to be used.
- Every CC test will spawn QEMU instance and whole tests will run under QEMU. tests should work out of box.
- ITF tests are currently executed (done via filter rule) only cc test and rust tests are included.
- QEMU ARM variant is also working.
- QNX workflow should always be triggered by a committer, will not run automatically.
Status of Valeo

CryptoKi library moved to backend folder
Temporary solution of PIN hashing is included. Only for testing. set via environment variable
Already tested by Werner and seems to be working
Performance improved
PR is ready for review and once the review is completed we can merge the changes
It is better to be merged as early as possible
we can take the other improvements like folder structure in next step

Status of IAV

PR is created with basic folder structure and hello world
Build is red. Once its resolved then it will be ready for review.
https://github.com/eclipse-score/inc_security_crypto/pull/77/changes#top

Committer elections raised by Volker
- Carolina Pelka and Tim Kaiser from IAV
- Athul from ETAS. Trigger Volker or check internally with other committers. R. Sunil

0 replies

sunildevda · 2026-07-14T10:40:53Z

sunildevda
Jul 14, 2026
Collaborator

15-July-26, 10-11 o'clock

Agenda:

[Organizational topic] Check participants
Testing on QNX8 crypto: Add qnx test execution for test binaries (cc_test) inc_security_crypto#70 - @OliverHeilwagen
- Changes completed. Pending due to QNX secret access PR approval: security_crypto: Enable QNX secrets. .eclipsefdn#206
Quality level expectation for Crypto integration in SCORE 0.9 release - @sunildevda
Minor fixes in crypto code Improve crypto daemon portability and provider resilience inc_security_crypto#84 - @antonkri
Hello world IAV Primula: IAV_Primula: "Hello World" for IAV_Primula inc_security_crypto#77 - @HeHa112
Valeo CryptoKi integration: Cryptoki etas integration inc_security_crypto#49 - @oeweda
Decision record of generic format for ACL: DR-003-ARCH-ACL-Concept: Generic Format for Access Control List #3058 - @christianbe9

Participants:

Minutes:

Testing on QNX8 crypto: Add qnx test execution for test binaries (cc_test) inc_security_crypto#70 - @OliverHeilwagen
- Changes completed. Pending due to QNX secret access PR approval: security_crypto: Enable QNX secrets. .eclipsefdn#206
- A ticket needs to be created an Issue/Ticket from security team. R. Sunil + Oliver
Quality level expectation for Crypto integration in SCORE 0.9 release - @sunildevda
- There is no concrete quality expectation needed for merging to Reference integration step.
- First step would be to rename from inc_crypto to crypto. This would be done by Otterdog. a reference of how this was done for time is available here: https://github.com/eclipse-score/.eclipsefdn/pull/201/changes
- Once this is done, inform Daniel and he will in-turn inform Anton.
- Crypto API looks ok and no major feedback or rework seen. Certificate related APIs being checked by BMW team.
Minor fixes in crypto code Improve crypto daemon portability and provider resilience inc_security_crypto#84 - @antonkri
- Changes are ready and reviewed.
- But blocked as ECA is not yet signed. Ugesh is already on it and will be done soon.
Hello world IAV Primula: IAV_Primula: "Hello World" for IAV_Primula inc_security_crypto#77 - @HeHa112
- Changes are done and can be merged.
- Next step will be work on IAV API Integrate IAV_Primula API inc_security_crypto#80
Valeo CryptoKi integration: Cryptoki etas integration inc_security_crypto#49 - @oeweda
- Review done by Athul. Rework will be done this week.
- Currently we can do end to end operations for MAC, Hash and some basic Key management operations.
- This PR is just to replace current SoftHSM with CryptoKi.
Decision record of generic format for ACL: DR-003-ARCH-ACL-Concept: Generic Format for Access Control List #3058 - @christianbe9
- ACL seems to be misleading, better to call it as Access Control
  -> could be done.
- Scope looks to be quite broad and not just limited to Access control. Ex. tlsenable, ipsecenable, criticality,...
  -> scope is for security features + access control. fields like Criticality can be dropped.
  -> idea is to have every access control that needs to enforced during runtime. Scope is not to define the complete crypto configuration but only one aspect of access control.
  -> Unicast use case is currently not supported
  -> Ugesh will also have a look.
- Is this access control for build time (folder and files permission) or run time (IPC, Crypto,..)?
  -> This decision record aim is to formalize the schema for configuration. it does not include folder and files permissions.
  -> Current idea is that this is OS agnostic Access control only. Currently it is only for run time use cases.
  -> This could be used for testing as well.
  -> first step is to align in security team here and then take it to other teams (IPC, SOME/IP,...)
- Access control use cases for Crypto
  1. Access control for keys -> Which application is allowed to use a key? Multiple applications can also be accessed.
  2. Access control for certificates -> same as keys.
  3. Access control (rate limiting) of number of crypto jobs -> Currently not added can be added.
  4. Access control (rate limiting) of memory crypto jobs -> Currently not added can be added.
  5. Access control for crypto jobs -> what kind of job can an application perform? Divide into different profiles. Ex.
  5.1 Profile 1: Hash, RNG
  5.2 Profile 2: Encryption/Decryption, Digital Signature/Verification,
  5.3 Profile 3: Certificate based operations (parsing, verification, CRL, OCSP, CSR)
  5.4 Profile 4: Key management (generation, derivation, export, import,..)
  5.4.1 Permission for key derivation
  5.4.2 Permission for generating a key
  5.4.3 Permission for generating and saving the key
  5.4.4 Permission for exporting the key -> "read"
  5.4.5 Permission for importing the key -> "write"
  - ...
  5.5 Profile x
  -> Should profile be done only offline tool
- Not in scope:
  1. Access control for which crypto provider to be used -> currently this is achieved via access control for Keys. Currently cross crypto provider is not considered.
  2. How to enforce it that modules are actually implementing as defined here?
  3. It does not look like we don't need a central parser at Baselib. Parsers could be part of respective module configuration parsers. This should be taken up at later step.

0 replies

sunildevda · 2026-07-21T13:47:27Z

sunildevda
Jul 21, 2026
Collaborator

22-July-26, 10-11 o'clock

Agenda:

[Organizational topic] Check participants
Testing on QNX8 crypto: Add qnx test execution for test binaries (cc_test) inc_security_crypto#70 -> @OliverHeilwagen → PR merged
IAV Primula hello world IAV_Primula: "Hello World" for IAV_Primula inc_security_crypto#77 -> @HeHa112 → PR merged.
Minor fixes Improve crypto daemon portability and provider resilience inc_security_crypto#84 → @antonkri -> PR merged.
Crypto component folder structure alignment: Initial module documentation inc_security_crypto#17 → @GuruprasadBhatL → PR created. Review
Backend concept Introduce backend-agnostic provider configuration and provider manager factory inc_security_crypto#92 → @ChansAlive → PR created. Review
- Merge conflict with the Cryptoki etas integration inc_security_crypto#49.
- Which PR to be merged first?
Integrate IAV_Primula API Integrate IAV_Primula API inc_security_crypto#80 → @HeHa112
CryptoKi integration Cryptoki etas integration inc_security_crypto#49 - @oeweda
Preperation for Crypto integration in SCORE 0.9 release - @sunildevda
Generic ACL DR-003-ARCH-ACL-Concept: Generic Format for Access Control List #3058 - @christianbe9 -> to be followed up next week.

Participants:

Minutes:

Testing on QNX8 crypto: Add qnx test execution for test binaries (cc_test) inc_security_crypto#70 -> @OliverHeilwagen → PR merged

only CC_Test and Rust tests are working.
ITF tests have to be taken up.

IAV Primula hello world IAV_Primula: "Hello World" for IAV_Primula inc_security_crypto#77 -> @HeHa112 → PR merged.
Minor fixes Improve crypto daemon portability and provider resilience inc_security_crypto#84 → @antonkri -> PR merged.
Crypto component folder structure alignment: Align folder structure as per score guidelines inc_security_crypto#114 → @GuruprasadBhatL → PR created. Review request.
- With this change we will have Crypto component as well
- Looks like all the architecture document that is currently present here: https://github.com/eclipse-score/inc_security_crypto/tree/main/docs/crypto/architecture should be moved under Crypto component documentation: score\crypto\docs
Backend concept Introduce backend-agnostic provider configuration and provider manager factory inc_security_crypto#92 → @ChansAlive → PR created. Ready for review
- Backends are now configurable.
- Custom configuration for each provider is possible in future. Parsing of configuration is hard coded currently.
- Tests are not yet adapted to select-able backend.
- PKCS11 library loading: if c_finalize can be done via function list.
- Werner tried this approach and worked perfectly.
- Step 1: Merge the CryptoKi PR Cryptoki etas integration inc_security_crypto#49. if there are no other points then can be merged quickly.
- Step 2: After this we then merge this backend PR.
- Step 3: Adapt the CryptoKi with the new backend infrastructure.
- Werner and Shorouk will add review points directly as comments into the PR.
CryptoKi integration Cryptoki etas integration inc_security_crypto#49 - @oeweda
- all review points addressed. Ready to be merged.
Preparation for Crypto integration in SCORE 0.9 release -
- Minimum expectation to achieve to be part of 0.9 reference integration:
- Integration of CryptoKi
- Migration of gRPC to lola
- Remove patches: https://github.com/eclipse-score/inc_security_crypto/blob/main/MODULE.bazel
  - gRPC related patches can be removed when migration to lola is done.
  - softhsm can be locally be there and in reference integration we can integrate only CryptoKi
  - softhsm examples should work out of box

Bare minimum documentation update for Crypto
Rename to inc_security_crypto → security_crypto
There is a risk that we have less time left to close the above points. we have to see how it goes.

Integrate IAV_Primula API Integrate IAV_Primula API inc_security_crypto#80 → @HeHa112

Working on the API level. on track. no blockers.

0 replies

sunildevda · 2026-07-28T13:16:31Z

sunildevda
Jul 28, 2026
Collaborator

29-July-26, 10-11 o'clock

Agenda:

[Organizational topic] Check participants
Crypto component folder structure alignment: Align folder structure as per score guidelines inc_security_crypto#114 → @GuruprasadBhatL → PR merged
Data plane changes: Integration of Data plane inc_security_crypto#10 → @GuruprasadBhatL -> PR to be created shortly
Discussion about dynamic loading v/s dynamic linking (ex. for PKCS11 libraries)
Backend concept Introduce backend-agnostic provider configuration and provider manager factory inc_security_crypto#92 → @ChansAlive → Review ongoing
Integrate IAV_Primula API: Integrate IAV_Primula API inc_security_crypto#80 → @HeHa112
CryptoKi integration: Cryptoki etas integration inc_security_crypto#49 - @oeweda

Participants:

Minutes:

Crypto component folder structure alignment: Align folder structure as per score guidelines inc_security_crypto#114 → @GuruprasadBhatL → PR merged .
- Not every content is filled in but we have all the structure and templates available and step by step we need to fill in the details.
Data plane changes: Integration of Data plane inc_security_crypto#10
- Changes are ready. PR will be created after the back-end changes are merged.
Discussion about dynamic loading v/s dynamic linking (ex. for PKCS11 libraries)
- Assumption use case: Our current understanding for pkcs11 provider is that in a project, we would have only one provider. There is no need for multiple pkcs11 libraries that we would have to integrate with crypto daemon.
- Even to work with the target pkcs11 library we have to build the score sources with the target toolchain and link the pkcs11 library to be used. (It is clear that tool chain cannot be part of public and in this case the whole rebuilding will be done in proprietary environment).
- Considering this, what is the real benefit we get using the dynamic loading?
- On the contrary, we see that complexity might increase with dynamic loading like config validation, version compatibility check etc.
- Use case: Integration of NxP PKCS11 HSE. But the header files are closed source (proprietary).
- Next step:
  - To add a compile time option to include both dynamic loading and dynamic linking option + include location of the PKCS11 target platform. Document the security implications of dynamic loading and also how these risks can be mitigated. Document this as assumption of use.
  - This can be done after back-end PR is completed and taken up as a separate task.
  - Task to be created offline R. Sunil
Backend concept Introduce backend-agnostic provider configuration and provider manager factory inc_security_crypto#92 → @ChansAlive → Review ongoing
- Will check PKCS11 HSE integration with latest change. will provide a feedback by Friday. R. Werner
- Feedback from Valeo will be provided by this week or early next week.
Integrate IAV_Primula API: Integrate IAV_Primula API inc_security_crypto#80 → @HeHa112
- still working on it . no blockers.
CryptoKi integration: Cryptoki etas integration inc_security_crypto#49 - @oeweda
- All changes are done. waiting for the backend PR to be merged.

1 reply

sunildevda Jul 30, 2026
Collaborator

follow up tasks for point 3 created:
eclipse-score/inc_security_crypto#135
eclipse-score/inc_security_crypto#134

sunildevda · 2026-07-31T14:30:37Z

sunildevda
Jul 31, 2026
Collaborator

05-Aug-26, 10-11 o'clock

Agenda:

[Organizational topic] Check participants
Data plane changes: Integration of Data plane inc_security_crypto#10 → @GuruprasadBhatL
Backend concept: Introduce backend-agnostic provider configuration and provider manager factory inc_security_crypto#92 → @ChansAlive
Access control for Crypto DR-003-ARCH-ACL-Concept: Generic Format for Access Control List #3058 (details below) -> @christianbe9
CryptotKi integration: Cryptoki etas integration inc_security_crypto#49
Integrate IAV_Primula API: Integrate IAV_Primula API inc_security_crypto#80 → @HeHa112

Participants:

Minutes:

see Screenshot (moderation @andilar)
@GuruprasadBhatL -> Data plane changes are in review, looking for committers for approval, status as as presented in June. PR order: 1st Backend PR, 2nd data plane
@ChansAlive -> Backend PR is shortly before finish, take some more days
@christianbe9 explained in detail the regarding PR for ACL, @ChansAlive added the details to the attached architectural overview
Access control overview for Crypto:

-> Waiting for acceptance of the PR for next steps 5. Waiting for closing of the Backend PR 6. Working on interface integration, PR should be ready this week, looking for Reviewers @EmbeddedSwGuy

0 replies

sunildevda · 2026-08-11T13:46:48Z

sunildevda
Aug 11, 2026
Collaborator

12-Aug-26, 10-11 o'clock

Agenda:

[Organizational topic] Check participants
Backend concept Introduce backend-agnostic provider configuration and provider manager factory inc_security_crypto#92 → @ChansAlive → PR merged
Data plane changes: Data plane implementation and integration inc_security_crypto#137 → @GuruprasadBhatL → PR merged
Adapt test to select the back-end: Guard backend-specific tests with target_compatible_with backend flags inc_security_crypto#150 → @ChansAlive → PR merged
Access control for Crypto DR-003-ARCH-ACL-Concept: Generic Format for Access Control List #3058 → @christianbe9
CryptotKi integration: Cryptoki etas integration inc_security_crypto#49 → @ShoroukRamzy
Integrate IAV_Primula API: Integrate IAV_Primula API inc_security_crypto#80 → @HeHa112
Support of dynamic loading : Support of dynamic loading inc_security_crypto#134 → any volunteers to do these changes? -> to be taken up next week.
- org-schreibwsag/inc_security_crypto@cb73290
Clean up/status for 0.9 release planning board

Participants:

Minutes:

Back-end concept Introduce backend-agnostic provider configuration and provider manager factory inc_security_crypto#92 → @ChansAlive → PR merged
Data plane changes: Data plane implementation and integration inc_security_crypto#137 → @GuruprasadBhatL → PR merged
Adapt test to select the back-end: Guard backend-specific tests with target_compatible_with backend flags inc_security_crypto#150 → @ChansAlive → PR merged
CryptotKi integration: Cryptoki etas integration inc_security_crypto#49 → @ShoroukRamzy
- Some build issues are there and is being resolved.
- How are rust crates resolved?
  - Currently in this PR there is a workaround.
  - A separate PR to be created to migrate to SCORE Crate. This is one of the prerequisite for being part of reference integration. Create a task. Make it part of Epic. Last time details of list of items for preparation for reference integration https://github.com/orgs/eclipse-score/discussions/2839?sort=new#discussioncomment-17717538 there is already a task for integration to reference integration here: Integration to reference integration repo inc_security_crypto#16 R. @sunildevda
- Target is to complete by early next week.
Integrate IAV_Primula API: Integrate IAV_Primula API inc_security_crypto#80
- Working on tests on API integration.
- Currently there is no secure storage for Key management implemented yet. there are only APIs defined, implementation is currently missing.
- Currently the keys are in file system for the tests. references:
- Hint: the ITF test is incorrect at the moment. this is being improved.
Access control for Crypto DR-003-ARCH-ACL-Concept: Generic Format for Access Control List #3058 → @christianbe9
- Certificate related access control details added.
- Read permission also added as there are some use cases where certificates may contain sensitive privacy data.
- Rename to following. Both for Certificate and keys: Read -> Export, Write -> Modify, Use
- Certificate and Certificate trust store are independent. Certificate trust store is collection of cert slots. Application can directly use the cert slots and not via trust store. both should be separated out.
- Discussion about what is access control related and what is remaining configuration related. To schedule a separate meeting for this next week with Christian, Athul and Sunil. Summary to be presented in the SCORE weekly meeting.
Clean up/status for 0.9 release planning board
- 0.9 release is coming up. due date is 7 Sep 2026 (code freeze is Aug 26). https://github.com/eclipse-score/score/milestone/31
- Idea is to check where do we stand for the upcoming release and either move the tasks or reduced scope to be part of the release.
- Backlog: SEC - Security FT (view)
- For the Epic Architectural improvements ETAS Archtiectural improvements ETAS inc_security_crypto#9 current status is topics in RED will not make it in for 0.9 release and in GREEN is on track.
  - Topics in RED to be removed from the above Epic and track these in another Epic. R. @sunildevda
- [Team Valeo] To check if the task Integration of PKCS11 (Cryptoki) With ETAS Architecture inc_security_crypto#32 is on track for 0.9 release R. @ShoroukRamzy
- [Team IAV] To check if the tasks under epic Cleanup IAV Primula for S-CORE usage inc_security_crypto#45 will be part of 0.9 release. if needed move them to a new Epic. R. @andilar
- We need to also discuss about what will make into the next SCORE v1.0 release from Crypto.
- Topic to be discussed again next week.

0 replies

sunildevda · 2026-08-18T14:57:10Z

sunildevda
Aug 18, 2026
Collaborator

19-Aug-26, 10-11 o'clock

Agenda:

[Organizational topic] Check participants
Access control for Crypto DR-003-ARCH-ACL-Concept: Generic Format for Access Control List #3058 → @christianbe9
Added POCs and Design Decision for IPC selection: https://github.com/eclipse-score/inc_security_crypto/pull/169 -> @selo -> PR created and reviewers?
Refactor integration tests for QNX ITF execution: https://github.com/eclipse-score/inc_security_crypto/pull/166 -> @OliverHeilwagen, Rework and further changes are ongoing. Reviewers?
Shared storage infrastructure and provider capability routing for certificate management (Prework for Certificate management related functionalities) -> https://github.com/eclipse-score/inc_security_crypto/pull/160 -> @ChansAlive -> PR created and reviewers?
Support of dynamic loading : Support of dynamic loading inc_security_crypto#134 -> https://github.com/eclipse-score/inc_security_crypto/pull/168 -> @schreibwsag -> PR created and review ongoing
- Do we need an environment variable to set the configuration path for the library?
CryptotKi integration: Cryptoki etas integration inc_security_crypto#49 → @ShoroukRamzy
Integrate IAV_Primula API: Integrate IAV_Primula API inc_security_crypto#80 → @HeHa112
Updates from weekly Tech leads meeting -> to be taken up next week
Backlog update
Can we execute more then one similar job (ex. two Hashing jobs) at same time in same process? -> to be taken up next week

Participants:

Minutes:

Access control for Crypto DR-003-ARCH-ACL-Concept: Generic Format for Access Control List #3058 → @christianbe9
- Discussion with Christian, Athul and Sunil ongoing. not yet reached a consensus/conclusion. Discussion will continue offline again this week and present the results here next week.
- Access control configuration should be able to split into multiple files.
- Processing of the access control to be also in respective features and not a central place.
- Avoid multiple context switches to check for access. Current idea is to have all access control within Crypto daemon, there is no central IAM being used and hence no context switches.
Added POCs and Design Decision for IPC selection: https://github.com/eclipse-score/inc_security_crypto/pull/169 -> @selo -> PR created and reviewers?
- In this PR the design decision for selection of different IPC mechanism is updated.
- POCs is just an experimental and will be removed shortly and can be skipped for review.
- Oliver and Shorouk will check this
Refactor integration tests for QNX ITF execution: https://github.com/eclipse-score/inc_security_crypto/pull/166 -> @OliverHeilwagen,
- new Bazel macro called integration_test.
- sources are .py test files, binaries, configs, file_pkgs (test vectors) and additional dependencies are also as input. Idea is to to put all the test vectors in this folder itself and reuse it for each backend.
- all of these used for tar creation.
- folder structure parts are preserved.
- file_pkgs: test vectors are centrally stored.
- theoretically possible to run multiple integration test in parallel but currently its not possible due to missing ITF/QEMU functionality.
- results are under tests\integration_tests\test.log
- test_linux.yml we can add different backends like IAV Primula, Cryptoki.
- currently based on ubuntu docker container, other features uses OCI rules (to create own images).
- long term hope is that entire environment set up is centralized, which each module/feature can reuse.
- Use cases for ITF: test on actual hardware, useful for crypto-daemon possible for component and feature integration test as well.
- CC_test could be used if we need to test only library or example IAV primula crypto provider without api daemon interaction.
- Current hashing and mac test implementation could be used as a reference for adding more tests (needs some clean up but can be used as reference).
Shared storage infrastructure and provider capability routing for certificate management -> Shared storage infrastructure and provider capability routing for certificate management inc_security_crypto#160
- Prework for Certificate management related functionalities
- multiple sub issues planned for certificate management. this is first step.
- code restructure to move deployments to a common folder structure.
- Capability based routing for default provider. After certificate is loaded, it can be done by any provider which supports certificate operations like openSSL. It is not needed that user has to select any provider during certificate context creation. internally daemon will check the available provider and select based on capability.
- Right now basic certificate management operations like certificate parsing, verification will be part. next will be CSR, OCSP, CRL,...
- If there are more then one providers supporting a capability, how is it decided which provider to be selected? if user is not given any specific provider then default provider will be used.
- Unlike key management, certificates are not tied up a provider. Storage could be optionally tied to a provider ex. PKCS11 cert storage or hardware assisted storage.
- How will root certificate path? root certificate will be stored in read only area and intermediate certificates will be stored in read-write area.
  - configuration is planned in Certificate config parsing inc_security_crypto#172.
  - Idea is to have a configuration possibility to support where the certificate have to be stored.
  - instead of giving particular root certificate, would help if we can select folder. to simplify certificate configuration management.
- Next steps for certificate are planned in this epic: Basic Certificate Management features inc_security_crypto#161
Support of dynamic loading : Support of dynamic loading inc_security_crypto#134 -> Add pkcs11 provider backend pkcs11_dynload inc_security_crypto#168
- Use case is to use PKCS11 library from actual hardware and not SoftHSM
- Idea is still to have only one PKCS11 module on the target.
- for testing -DALLOW_PKCS11_LIB_OVERRIDE could be used. This should be written as assumption of use to not use environment variable.
CryptotKi integration: Cryptoki etas integration inc_security_crypto#49 → @ShoroukRamzy
- all review findings are implemented.
- There will be follow up issues and tickets.
- Athul will do the final check and approve it or add new points/follow up tasks.
Integrate IAV_Primula API: Integrate IAV_Primula API inc_security_crypto#80 → @HeHa112
- internal review, documentation and test ongoing. no blockers. once this is done a PR will be created.
Backlog status:
- ETAS: New epic created and topics moved to these epics. Details here: SEC - Security FT (view)
- Valeo: the task Integration of PKCS11 (Cryptoki) With ETAS Architecture inc_security_crypto#32 can be marked as duplicate of PKCS11 (Cryptoki) Integration with SCORE inc_security_crypto#31 and can be removed.
- IAV: New epic to be created and

0 replies

sunildevda · 2026-08-25T10:05:51Z

sunildevda
Aug 25, 2026
Collaborator

26-Aug-26, 10-11 o'clock

Agenda:

[Organizational topic] Check participants
Volunteers for coordination of next weeks meeting?
Updates from weekly Tech leads meeting
Support of dynamic loading : Support of dynamic loading inc_security_crypto#134 -> Add pkcs11 provider backend pkcs11_dynload inc_security_crypto#168 -> @schreibwsag
CryptotKi integration: Cryptoki etas integration inc_security_crypto#49 → @ShoroukRamzy
Integrate IAV_Primula API: Integrate IAV_Primula API inc_security_crypto#80 → @HeHa112
Can we execute more then one similar job (ex. two Hashing jobs) at same time in same process? @ugeshmunirjulu
Access control for Crypto: DR-003-ARCH-ACL-Concept: Generic Format for Access Control List #3058 → @christianbe9
OpenSSL Provider: Support AES-CBC cipher, Random number and ECDSA → https://github.com/eclipse-score/inc_security_crypto/pull/181→ @prabakaranklst
Added POCs and Design Decision for IPC selection: Added POCs and Design Decision for IPC selection inc_security_crypto#169 -> @selo
Refactor integration tests for QNX ITF execution: crypto: refactor integration tests for QNX ITF execution inc_security_crypto#166 -> @OliverHeilwagen ,
Shared storage infrastructure and provider capability routing for certificate management -> Shared storage infrastructure and provider capability routing for certificate management inc_security_crypto#160 -> @ChansAlive

Participants:

Minutes:

Skip next weeks meeting. Create a minutes for next week and mention it as cancelled. R. Sunil
Updates from weekly Tech leads meeting
- Reference: https://github.com/orgs/eclipse-score/discussions/434#discussioncomment-18048797
- Announced that crypto will not make it 0.9 release.
- Module_template restructuring being discussed.
- Naming clean up. Use security_crypto or crypto everywhere: https://eclipse-score.github.io/.github/#naming
  - Module name to be score_security_crypto
  - understand what is the reason for red for docs/features/crypto. Check with Roland. R. Sunil
  - Will add this to the Epic for integration to reference integration repo.
CryptotKi integration: Cryptoki etas integration inc_security_crypto#49 → @ShoroukRamzy
- PR merged.
- But getting QNX build errors: https://github.com/eclipse-score/inc_security_crypto/actions/runs/32856260293/job/97828876722 needs to be checked on priority.
- We have following options:
  1. fix the above issue asap, so that we unblock others
  2. exclude the PKCS11 from the code. Example command bazel build //score/... --config=x86_64-qnx -- -//score/cryptoki/...
  3. revert the changes back -> this is not a good idea.
  - To check for option 1 and if this does not work, switch to option 2. Feedback by today. R. @ShoroukRamzy
  - CI runs can be executed only by committers.
  - Once the changes are checked locally, inform ETAS (Sunil, Oliver or Athul or in SCORE channel) and one of the committers will check it if its works.
- Follow up tasks created for further clean ups which are needed for the next step of integration to reference integration repo
  1. Migrate openssl-sys to score-crates and align version synchronization inc_security_crypto#183
  2. Drop deprecated score_baselibs_rust dependency and bump score_baselibs to v0.2.9 inc_security_crypto#184
  3. Resolve score_logging compile crashes upstream and remove local temporary patch inc_security_crypto#185
Support of dynamic loading : Support of dynamic loading inc_security_crypto#134 -> Add pkcs11 provider backend pkcs11_dynload inc_security_crypto#168 -> @schreibwsag
- rebased with the latest PKCS11 changes as well and is ready to be merged.
- Check with Athul to merge this
Integrate IAV_Primula API: Integrate IAV_Primula API inc_security_crypto#80 → @HeHa112
- QNX build issue. will try the workaround mentioned in point 3.
- Work is ongoing.
Can we execute more then one similar job (ex. two Hashing jobs) at same time in same process? @ugeshmunirjulu
- Use case: One crypto job is ongoing and there is one more crypto job coming from diagnostic job.
- data_manager.cpp (line 511-515): Two requests coming from same clientId is checked and returns resource busy.
- This is done to restrict the scoping of uid.
- Crypto is not thread safe, so using the same context in two different threads will not work.
- However, it is possible to create two different context in two different threads.
- If underlying TEE/HSM is busy and the new operation has to be repeated till TEE/HSM is free. How to handle this?
  - Option 1: should crypto provider have the retry? this will impact the timeout functionality (coming from ASIL requirement) or
  - Option 2. should this be passed on application and application does a retry?
    Think about this and document this in our architect. sounds like a provider specific topic. R. ETAS
OpenSSL Provider: Support AES-CBC cipher, Random number, Key permission and ECDSA → https://github.com/eclipse-score/inc_security_crypto/pull/181→ @prabakaranklst
- Adding support for new Crypto jobs AES-CBC for all 3 key sizes, Random number (includes seeding as well), ECDSA (for three different NIST curves)
- Key permission checks were missing and is added as part of this PR
- Files from future module folder moved to regular folder
- Code works for OpenSSL provider
- Move the test vector to separate folder as done in MAC and hashing. Idea is to reuse this across multiple test levels and across multiple providers.
- It is not mandatory to seed the random number generator. It is possible to
- How will it handle when there is not enough entropy? OpenSSL returns error and this is passed over to application or fill it with software pattern as recommended by NIST.
- ETAS will check this.
Access control for Crypto: DR-003-ARCH-ACL-Concept: Generic Format for Access Control List #3058 → @christianbe9
- DR extended to consider different aspects of access control for crypto jobs, key management and certificate operations (basically all different aspects of crypto is considered)
- Supports both fine grained control as well broad controls
- Many things are optional
- Everything related to Crypto is now done unless there are any other review findings
- Add the pictures to the PR that were used during discussion. R. @christianbe9
- Review these changes and give feedback. R. everyone
Added POCs and Design Decision for IPC selection: Added POCs and Design Decision for IPC selection inc_security_crypto#169 -> @selo
- PR available and waiting for review
Refactor integration tests for QNX ITF execution: crypto: refactor integration tests for QNX ITF execution inc_security_crypto#166 -> @OliverHeilwagen ,
- PR available and waiting for review
Shared storage infrastructure and provider capability routing for certificate management -> Shared storage infrastructure and provider capability routing for certificate management inc_security_crypto#160 -> @ChansAlive
- PR available and waiting for review

0 replies

sunildevda · 2026-08-26T11:51:13Z

sunildevda
Aug 26, 2026
Collaborator

02-Sep-26, 10-11 o'clock

Agenda:
Meeting cancelled due to holidays. Discussion will continue on 09-Sep-26. For any urgent topics please write to security slack channel: https://app.slack.com/client/T02MS1M89UH/C0B0F1J914Z

0 replies

sunildevda · 2026-09-08T14:38:33Z

sunildevda
Sep 8, 2026
Collaborator

09-Sep-26, 10-11 o'clock

Agenda:

[Organizational topic] Check participants
PR's closed since last meeting:
- Add pkcs11 provider backend pkcs11_dynload inc_security_crypto#168 -> @schreibwsag
- coverage: adopt the LLVM coverage pipeline from score_tooling 2.2.1 inc_security_crypto#198 -> with this PR now we have a code coverage available
Ideas to improve the weekly meetings?
- Too many topics to discuss in 1 hour.
- Many PR's waiting for review.
- ...
7 PR's ongoing + 1 in draft (PRs arranged below in order of creation. Oldest being first)
Access control for Crypto: DR-003-ARCH-ACL-Concept: Generic Format for Access Control List #3058 → @christianbe9
- Images were lost. New image recreated and currently being reviewed by ETAS.
Migration of hashing functionality from Baselibs to Crypto: Migration of hashing from Baselibs to Crypto repo inc_security_crypto#125 -> @kssim
Backlog grooming: SEC - Security FT (view)

Participants:

Minutes:

PR's closed since last meeting:
- Add pkcs11 provider backend pkcs11_dynload inc_security_crypto#168 -> @schreibwsag
- coverage: adopt the LLVM coverage pipeline from score_tooling 2.2.1 inc_security_crypto#198 -> with this PR now we have a code coverage available
Ideas to improve the weekly meetings?
- Collaboration is going good.
- Separate Technical deep dive sessions makes sense and then present the conclusions here.
- Improve the planning. Focus on what needs to be done for reference integration and features for next release 0.10
Backlog grooming: SEC - Security FT (view)
- SCORE 1.0 Milestone release due date 14 Dec 2026 https://github.com/eclipse-score/score/milestone/27
- Crypto product increment 0.10 https://github.com/eclipse-score/inc_security_crypto/issues/112
- Idea is to align on the feature sets that we need to bring in next program iteration
- Create a task for the OpenSSL Provider: Support AES-CBC cipher, Random number and ECDSA inc_security_crypto#181 R. Sunil
7 PR's ongoing + 1 in draft (PRs arranged below in order of creation. Oldest being first)
1. Shared storage infrastructure and provider capability routing for certificate management inc_security_crypto#160 -> @ChansAlive
  - Waiting for review. Would be checked with Ugesh to have a look.
2. crypto: refactor integration tests for QNX ITF execution inc_security_crypto#166 -> @OliverHeilwagen
  - Review + rework ongoing.
3. Added POCs and Design Decision for IPC selection inc_security_crypto#169 -> @se-lo
  - Some more changes were added and decision was updated.
  - Target of the review is to check the decision for choosing the IPC mechanism.
  - there will be some more changes coming in to get the build issues resolved but this is only for PoC and not needed to be reviewed.
  - Shorouk will also check this but there is issue in adding the name as reviewer. To be checked offline. R. Sunil
4. OpenSSL Provider: Support AES-CBC cipher, Random number and ECDSA inc_security_crypto#181 -> @prabakaranklst
  - NIST test vectors added. Waiting for review.
5. [new] cryptoki: fix QNX build and tests inc_security_crypto#196 -> @OliverHeilwagen
  - Review completed. Rework is ongoing.
  - There are some QNX flaky tests that are failing and we need to investigate why its happening.
6. [draft] Certificate Management Daemon Component inc_security_crypto#197 -> @ChansAlive
  - To be taken up after the current prequisite for certificate management PR Shared storage infrastructure and provider capability routing for certificate management inc_security_crypto#160 is available.
  - Some more changes are being done in parallel and once its ready will be presented here.
7. [new] iav_primula: add first integration dummy inc_security_crypto#199 -> @HeHa112
  - Dummy implementation for APIs will return feature unsupported. PR is ready for review.
  - In next step the actual algorithms will be implemented and is planned under Use the post-quantum algorithms from the PQCleanAutomotive repository inc_security_crypto#53
  - Documentation is also ongoing and will be part of another PR Create the documentation for task #53 and #80 inc_security_crypto#81
  - Provider is under backend in parallel to openSSL provider
8. [new] remove baselibs rust and logging patches inc_security_crypto#204 -> @ShoroukRamzy
  - PR is ready for review.
  - There are some issues with score_baselibs", version = "0.2.12" (changes are being planned to resolve it in baselib PRs. so in this PR the first step is to move to score_baselibs", version = "0.2.10" and then in next step bump it to 0.2.12 version.

0 replies

sunildevda · 2026-09-14T19:34:28Z

sunildevda
Sep 14, 2026
Collaborator

16-Sep-26, 10-11 o'clock

Agenda:

[Organizational topic] Check participants
PR's closed since last meeting:
Status of ongoing PR's ongoing (PRs arranged below in order of creation. Oldest being first)
Other topics:
- Access control for Crypto: DR-003-ARCH-ACL-Concept: Generic Format for Access Control List #3058 → @christianbe9
- Migration of hashing functionality from Baselibs to Crypto: Migration of hashing from Baselibs to Crypto repo inc_security_crypto#125 -> [@kssim]
- (new) defect: Revise strategy to derive SHM name in data plane implementation Revise strategy to derive SHM name in data plane implementation inc_security_crypto#224
SBOM generation
How to handle when HSM/TEE is busy
- Continuation of point 6 in the SCORE meeting raised by Ugesh from BMW https://github.com/orgs/eclipse-score/discussions/2839?sort=new#discussioncomment-18146858
- Discussion of different solutions
Unstable in the tests -> to be taken up next week
Backlog grooming -> to be taken up next week
- There is a deep dive session for planning of certificate management planned this Friday. if anyone wants to join.

Participants:

Minutes:

PR's closed since last meeting:
- cryptoki: fix QNX build and tests - #196 -> @OliverHeilwagen
- crypto: refactor integration tests for QNX ITF execution - #166 -> @OliverHeilwagen
- crypto: Enable run_under_qemu to avoid cap_net_raw - #226 -> @ChansAlive
- There are tests running for each PR merge on linux for all three crypto providers (SCORE, OpenSSL and Cryptoki). For QNX only the unit tests are running.
- Issue: Enable the build for Linux ARM (testing can be omitted)
Status of ongoing PR's ongoing (PRs arranged below in order of creation. Oldest being first)
- Shared storage infrastructure and provider capability routing for certificate management inc_security_crypto#160 -> @ChansAlive
  - Review done and rework ongoing. will be completed shortly.
- Added POCs and Design Decision for IPC selection inc_security_crypto#169 -> @se-lo
  - Rebase with the baselib version (rust logging patching is already available. Sharedmemory moved from baselibs to com)
  - Waiting for review
- OpenSSL Provider: Support AES-CBC cipher, Random number and ECDSA inc_security_crypto#181 -> @prabakaranklst
  - waiting for review
- [draft] Certificate Management Daemon Component inc_security_crypto#197 -> @ChansAlive
  - some more changes are ongoing. will be bought after the current certificate PR is merged.
- iav_primula: add first integration dummy inc_security_crypto#199 -> @HeHa112
  - There is a commit coming from depeandabot https://github.com/eclipse-score/inc_security_crypto/pull/199/changes#diff-f277aa99e31d86be7bfaaacb3238ac2b61868d5915a46c8bf789ac624dbc81b0
  - Change was coming in the commit: eclipse-score/inc_security_crypto@64e9e2e5
  - Change was only the cargo.lock is updated. toml file is not yet updated. this looks strange and could be ignored. more details to be checked with Infra team.
  - Waiting for review.
- remove baselibs rust and logging patches inc_security_crypto#204 -> @ShoroukRamzy
  - Review and rework completed.
  - OpenSSL to be moved to another repo. Contact person is Alexander Lanin from ETAS. Some changes in Otterdog would be needed. Would be taken as separate task.
  - Also, investigating the flaky tests.
  - ready to be merged. R. Athul
- (new bugfix) Use proper settings for concurrency. Fix pre-commit hook inc_security_crypto#231 -> @se-lo
  - There is no multi thread for a session. only one thread per session.
  - Minor bug fix introduced. review findings received.
  - Waiting for one feedback for testing from Werner
- (new) Use only established secure zeroize APIs inc_security_crypto#232 -> @GuruprasadBhatL
  - minor changes.
  - review done. finalize changes.
Other topics:
- Access control for Crypto: DR-003-ARCH-ACL-Concept: Generic Format for Access Control List #3058 → @christianbe9
  - same status. waiting for the images to be redrawn.
- Migration of hashing functionality from Baselibs to Crypto: Migration of hashing from Baselibs to Crypto repo inc_security_crypto#125 -> [@kssim]
  - PRs created and ready for review.
  - in general we need to wait for removal of baselibs as Crypto is not yet part of the reference integration repo. we need to keep this as draft.
  - https://github.com/eclipse-score/inc_security_crypto/pull/237/changes -> To be reviewed.
  - feat(hash): remove OpenSSL-backed algorithms baselibs#588 ->
  - Order: 1. Bring the changes in Security Crypto 2. Bring the Security crypto to reference integration test 3. then update config management . remove baselibs.
  - Some more tests will be done in parallel and any changes will be updated. currently tests are passing on CI.
- (new) defect: Revise strategy to derive SHM name in data plane implementation Revise strategy to derive SHM name in data plane implementation inc_security_crypto#224
  - change the naming pattern and this will solve the issue.
SBOM generation
- https://github.com/eclipse-score/reference_integration/pull/304/changes
- Two types of SBOM. one for development tools and another for actual product dependencies.
- Bazel target might have loop holes to set up the SBOM for development tools. but for actual target dependencies there is no issues.
- Dev dependencies SBOM will be more meaningful for module level as reference
- Where should the SBOM be stored? in the security management folder strcuture for each module and platform : https://eclipse-score.github.io/module_template/main/template/index.html
How to handle when HSM/TEE is busy
- Continuation of point 6 in the SCORE meeting raised by Ugesh from BMW https://github.com/orgs/eclipse-score/discussions/2839?sort=new#discussioncomment-18146858
- Possible solutions:
  - Option 1: No queue or internal retry in crypto. Application does a retry -> current implementation
    - Crypto returns resource_busy till the underlying HSM/TEE has completed the job
  - Option 2: Retry in Daemon
    - This will impact the timeout functionality (coming from ASIL requirement). This will also mean crypto provider will have a queue.
    - Introduce complexity to solve following aspects:
    - Configurable queue size
    - Should the queue be a provider specific or daemon?
    - What should be the gap within two retries?
      - Option a: configurable option for delay between retry
      - Option b: immediate retry.
    - Quite complex design in crypto daemon needed.
  - Option 3: (configurable) Retry in the crypto API itself
    - No handling or changes in daemon. Retry in API.
    - return values:
      - resource_timeout (all retires were unsuccessful till the timeout)
      - (resource_retry_reached →) resource_busy (all retries were unsuccessful and before timeout was reached)
    - default value is retry till timeout
    - (configurable) Otherwise till the retry count reaches which is configurable
    - what is the gap between two retries?
      - Option a: configurable option for delay between retry
      - Option b: immediate retry.
      - Option b is better.
    - ETAS preference: option 3 is less complex and balance between timeout, retries and complexity.
    - Hardware provider vs software provider: even software provider could be busy example when the PKCS11 tokens for openssl provider are exhausted or the keys have to be accessed.
    - In general, the solution is to use the same solution for software or hardware provider.
    - Next step: to start with option 3 first and then can be extended to include option 2.
    - To be discussed internally and provide feedback. R. Ugesh
PIN handling for PKCS11
- current implementation is limited and needs to be extended. PIN should not be exposed in normal world.

sunildevda
Sep 22, 2026
Collaborator

23-Sep-26, 10-11 o'clock

Agenda:

[Organizational topic] Check participants
PR's closed since last meeting
Backlog grooming
Status of ongoing PR's ongoing (PRs arranged below in order of creation. Oldest being first)
How to address review backlog?
Other topics:
- Access control for Crypto: DR-003-ARCH-ACL-Concept: Generic Format for Access Control List #3058 → @christianbe9
- OpenSSL to be a separate repo. https://github.com/Valeo-S-CORE-Organization/inc_security_crypto_valeo_pitch/tree/test-openssl/third_party/score_openssl -> @ShoroukRamzy
Instability in the tests
Code owner

Participants:

Minutes:

PR's closed since last meeting:
Backlog grooming:
- Two upcoming releases in SCORE:
  - v0.10 - Due date 02 Nov 2026
  - v1.0 - Due date 13 Dec 2026
- Target is to get the Crypto changes in SCORE 1.0 Milestone release due date 13 Dec 2026 https://github.com/eclipse-score/score/milestone/27
- Crypto product increment 0.10 https://github.com/eclipse-score/inc_security_crypto/issues/112
  - First stable release of Crypto and integration to reference integration repo
  - Support of basic crypto functionalities (Hashing, MAC, AES encryption/decryption, Signature verification and generation, Key generation) with OpenSSL crypto provider.
  - Integration of CryptoKi PKCS11 crypto driver
  - Integration of PQC Primula (library + crypto driver)
  - Configuration concept for Crypto
  - Support of basic certificate management features (parsing, verification of cert and cert chain, trust store concept,..)
- Feedback from Tech lead meeting (https://github.com/orgs/eclipse-score/discussions/434?sort=new#discussioncomment-18535743): To plan things earlier and avoid one big bang integration.
Status of ongoing PR's ongoing (PRs arranged below in order of creation. Oldest being first)
- https://github.com/eclipse-score/inc_security_crypto/pull/160 -> @ChansAlive
  - Review, rework and approval from Ugesh done.
  - Review from Oliver ongoing.
- https://github.com/eclipse-score/inc_security_crypto/pull/169 -> @selo
  - Waiting for review
- https://github.com/eclipse-score/inc_security_crypto/pull/181 -> @prabakaranklst
  - Review from Athul ongoing
- [draft] https://github.com/eclipse-score/inc_security_crypto/pull/197 -> @ChansAlive
  - To be taken up after point 1.
- https://github.com/eclipse-score/inc_security_crypto/pull/199 -> @HeHa112
  - Seems to have conflict with point 4. Signer implementation is touched.
- Use proper settings for concurrency. Fix pre-commit hook - #231 -> @selo
  - Review ongoing
- https://github.com/eclipse-score/inc_security_crypto/pull/237 -> @kssim
  - Waiting for review
- [new draft]: https://github.com/eclipse-score/inc_security_crypto/pull/250 -> @ChansAlive
  - To be taken up after point 1.
- [new draft]: https://github.com/eclipse-score/inc_security_crypto/pull/251-> @ChansAlive
  - To be taken up after point 1.
- [new] https://github.com/eclipse-score/inc_security_crypto/pull/253 -> @ShoroukRamzy
  - Review is done and only thing now pending is have to first merge the changes in mw:log
How to address review backlog?
- Dedicated review capacity reserved from ETAS and reviews will be faster
- Recommended to have small PRs so that the review is faster
Other topics:
- Access control for Crypto: DR-003-ARCH-ACL-Concept: Generic Format for Access Control List #3058 → @christianbe9 -> to be taken up later
- OpenSSL to be a separate repo. https://github.com/Valeo-S-CORE-Organization/inc_security_crypto_valeo_pitch/tree/test-openssl/third_party/score_openssl
  - Circular dependency between score_crates, opensll and crypto.
  - Started discussion with Alexander Lanin on creating a separate openssl repo
  - What is the dependency of score_crates on openssl? This is a transient dependency.
  - Is this a long term dependency? R. Shoruk
Instability in the tests
- QNX variant has lots of flaky tests.
- Needs QNX build access to investigate the tests.
- Its not a blocker for reference integration and can be taken up at later point as well based on the capacity. R. Valeo team.
Code owner:
- There is an election for being a code owner.
- Create a PR with update of code owner. Add Volker as reviewer.
- We can code owner for each folder (if needed) and also different scope.
- Reference as done in SCORE: https://github.com/eclipse-score/score/blob/main/.github/CODEOWNERS. on similar lines we need to update the changes for https://github.com/eclipse-score/inc_security_crypto/blob/main/.github/CODEOWNERS

0 replies

sunildevda · 2026-09-29T09:55:36Z

sunildevda
Sep 29, 2026
Collaborator

30-Sep-26, 10-11 o'clock

Agenda:

[Organizational topic] Check participants
PR's closed since last meeting
Status of ongoing PR's ongoing (PRs arranged below in order of creation. Oldest being first)
OpenSSL to be a separate repo: https://github.com/Valeo-S-CORE-Organization/inc_security_crypto_valeo_pitch/tree/test-openssl/third_party/score_openssl @ShoroukRamzy

Participants:

Minutes:

PR's closed since last meeting
- crypto: x86_64-qnx set qemu cpu for consistent ci behavior. inc_security_crypto#258 -> @OliverHeilwagen
- Cryptoki: Fix aarch64-linux build inc_security_crypto#253 -> @ShoroukRamzy
- Use proper settings for concurrency. Fix pre-commit hook inc_security_crypto#231 -> @selo
- And couple of more PR's from central rollout.
- The changes were primarily maintenance and build-system improvements.
Status of ongoing PR's ongoing (PRs arranged below in order of creation. Oldest being first)
- Shared storage infrastructure and provider capability routing for certificate management inc_security_crypto#160 -> @ChansAlive
  - Review, rework and approval from Ugesh done.
  - Review from Oliver done. Rework done.
  - Volker will check and final approval
  - Will also update code owners. R. Volker
- Added POCs and Design Decision for IPC selection inc_security_crypto#169 -> @selo
  - Waiting for review
- OpenSSL Provider: Support AES-CBC cipher, Random number and ECDSA inc_security_crypto#181 -> @prabakaranklst
  - First round of review and rework done. Next round of rework and review will be done this week.
  - Some improvements identified and follow up tasks created. Will be taken up after the current PR. Will decide next week.
  - User Interface Refactor inc_security_crypto#261
  - Key management sub context inc_security_crypto#262
  - Adapt the Handler Interface inc_security_crypto#263
- [draft] Certificate Management Daemon Component inc_security_crypto#197 -> @ChansAlive
  - To be taken up after point 1.
  - This will be re-based and published soon. Oliver, Laszlo, Shoruk and Ugesh will review the PR.
  - First PR related to Certificate management. Core component in the daemon will be introduced.
  - Concept like Trust stores, CRL, OpenSSL provider, basic expected configuration elements is also present.
  - Minimal documentation and tests are already present.
  - It is not usable from application as the API and configuration is not yet in this PR. They are part of the below two PRs. Since the PRs are big.
  - Context are created but not all are enabled. only basic ones like Cert verification is enabled. (CSR context will be updated in next step)
  - TrustStoreManager enforces the access control policy. This is a collection of various CertSlots. Manages membership of the CertSlots. Exclusive slot are for TrustStore itself.
  - CertSlotManager: Certificates can be either in file system or in hardware. Accessed via CertSlot. conditional relationship with TrustStoreManager.
  - Breakout session to be planned once the first look at the PR is done by reviewers. To be taken up in next meeting.
  - Picture about the different elements of Certificate management

 - https://github.com/eclipse-score/inc_security_crypto/pull/199 -> @HeHa112
      - Review completed. Rework ongoing. No open points. 
      - Have conflicts with the Qorix PR (item 3) and have to be rebased. 

 - https://github.com/eclipse-score/inc_security_crypto/pull/237 -> [@kssim](https://confluence.etas-dev.com/spaces/PFCMW/pages/748394621/2026-09-11)
      - Waiting for review
      - Athul will have a look at this after the item 3 and 4 are done above. 
       
 -  [draft]: https://github.com/eclipse-score/inc_security_crypto/pull/250 -> @ChansAlive
      - To be taken up after point 1.  
      
 - [draft]: https://github.com/eclipse-score/inc_security_crypto/pull/251 -> @ChansAlive
      - To be taken up after point 1.

OpenSSL to be a separate repo. https://github.com/Valeo-S-CORE-Organization/inc_security_crypto_valeo_pitch/tree/test-openssl/third_party/score_openssl @ShoroukRamzy
- Discussion with Alexander Lanin ongoing. Some issues in creation of repo. Being checked.
- Minor PRs will be added. Last weeks open points (depedency with openssl and crates) will be followed up in next meeting.

0 replies

sunildevda · 2026-10-06T09:37:11Z

sunildevda
Oct 6, 2026
Collaborator

07-Oct-26, 10-11 o'clock

Agenda:

[Organizational topic] Check participants
PR's closed since last meeting
Status of ongoing PR's
Certificate management: CSR concept, cross provider handling
IPC migration

Participants:

Minutes:

PR's closed since last meeting:
https://github.com/eclipse-score/inc_security_crypto/pull/160 -> @ChansAlive
https://github.com/eclipse-score/inc_security_crypto/pull/266 -> @PandeDo

some more PR's for dependency and repository maintenance.

Status of ongoing PR's ongoing (PRs arranged below in order of creation. Oldest being first)
1. https://github.com/eclipse-score/inc_security_crypto/pull/169 -> @selo
  - Waiting for review
2. https://github.com/eclipse-score/inc_security_crypto/pull/181 -> @prabakaranklst
  - Rework done.
  - Final check to be done and will merge the PR.
  - Following improvement tasks to be done next.
    - User Interface Refactor inc_security_crypto#261 -> will start with this improvement.
    - Key management sub context inc_security_crypto#262
    - Adapt the Handler Interface inc_security_crypto#263
    - One more improvement found and need to create a ticket for this. To be checked an a ticket to be created. R. Athul, Sunil
3. [open] https://github.com/eclipse-score/inc_security_crypto/pull/197 -> @ChansAlive
  - Review + rework ongoing
  - Review from Ugesh is ongoing. Will need one or two days more to complete the review.
  - Rework can be started for the current review comments.
  - Need a separate breakout for deep dive. Monday will be ok. Lazlo, Ugesh, Athul, Sunil. R. Sunil
4. https://github.com/eclipse-score/inc_security_crypto/pull/199 -> @HeHa112
  - Review completed. Rework ongoing.
  - Have conflicts with the Qorix PR (item 3) and have to be rebased.
  - Key management will be handled by Provider and metadata by the key management.
  - Some basic architecture diagrams are there under the docs folder.
5. https://github.com/eclipse-score/inc_security_crypto/pull/237 -> @kssim
  - Review ongoing. First level findings will be shared shortly.
  - Better to mention migration from Baselibs to Crypto related information into a task. AoUs is not the right place (as they are temporary and will be invalid once the migration is completed).
6. [draft]: https://github.com/eclipse-score/inc_security_crypto/pull/250 -> @ChansAlive
  - To be taken up after point 3
  - Review ongoing from @GuruprasadBhatL
7. [draft]: https://github.com/eclipse-score/inc_security_crypto/pull/251-> @ChansAlive
  - To be taken up after point 2.
  - No new changes. Feel free to have an early look at the implementation and try out.
  - Has Client related changes (API). With this basic certificate related operations like Cert paring, Cert verification, Trust store management and so on is possible.
  - Ugesh will already have a look at the PR.
  - Extraction of key from certificate is not yet part of the PR.
8. OpenSSL related topics -> @ShoroukRamzy
  1. OpenSSL movement: Move OpenSSL to a separate repo: Move OpenSSL to a separate repo inc_security_crypto#272
    - New repo for OpenSSL created: https://github.com/eclipse-score/openssl
    - Ongoing. PR will be created soon.
      2. Move OpenSSL -sys crate to score crate and use the above openssl: Migrate openssl-sys to score-crates and align version synchronization inc_security_crypto#183
    - Ongoing. PR will be created soon.
      3. Update OpenSSL version in baselibs to the above openssl: https://github.com/eclipse-score/inc_security_crypto/issues/273
      4. Adapt score crypto to use mw::com shared memory, bumb baselibs, depend on the above openssl repo and score crates: Adapt Daemon to use shared memory coming from mw::com inc_security_crypto#227
      - This is already being done as part of Migration of gRPC to mw:com (lola) inc_security_crypto#11 by Sebastian. Will create a seperate PR already for this. R. Sebastian.
      - The current patch https://github.com/eclipse-score/inc_security_crypto/blob/aa0727ba5ef27b2190d644181f996df141f77756/MODULE.bazel#L338-L342 will also be addressed.
9. [new] https://github.com/eclipse-score/inc_security_crypto/pull/276 -> @ShoroukRamzy
  - Minor changes to remove the dependency.
  - PR will be Oliver will have a look at it.
Reference integration milestone:
- some more improvements identified by Shoruk and will be shared shortly.
- Got a list of steps to be done here: https://eclipse-score.github.io/reference_integration/main/integration_process/integration_process.html. Will check if anything is unplanned yet. R. Sunil
Certificate management: CSR concept, cross provider handling
- Current set up in BMW project. keys are stored in trust store.
- X509 provider needs to access/serialize the key for signing.
- For use case CSR (Certificate Signing Request).
- Basically what we need is a Cross context handling be done?
- Currently there are no concept or changes for this.
- Another use case is provider to provider access.
- Task existing in backlog: Concept for cross context operations inc_security_crypto#209
- Current impression (from ETAS) is that there might not be major changes in the API level for the current certificate PRs. There might be changes in Key management but not much changes in the Certificate management.
- Will discuss about this (initial ideas) in coming days.
- There are some lessons learnt which should be avoided. To be discussed with the topic comes up.
IPC migration
- ongoing as part of Migration of gRPC to mw:com (lola) inc_security_crypto#11
- On track for the reference integration milestone.
- Create a document about the current idea and present in next weeks meeting. R. Sebastian
Test improvements
- Some concurrency tests are there but they are not extensive. Current tests: score/tests/integration_tests/hash_performance_test.cpp
- Makes sense to have concurrency for sub components
- Integration level tests with multiple clients is currently being evaluated. PR will be created for this in SCORE. R. Ugesh
How IAV crypto functionality can be accessed?
- IAV Crypto provider is in parallel to OpenSSL. It is not possible to access the IAV Crypto provider via OpenSSL.
- Daemon is an aggregator of different providers. Application will be agnostic of underlying provider.
- Current roadmap for IAV Primula integration is under this Epic: Cleanup IAV Primula for S-CORE usage inc_security_crypto#45

0 replies

sunildevda · 2026-10-13T12:39:00Z

sunildevda
Oct 13, 2026
Collaborator

Agenda:

[Organizational topic] Check participants
PR's closed since last meeting
Status of ongoing PR's

Participants:

Minutes:

PR's closed since last meeting:
- Use shm from communication, update deps, deprecations as warnings inc_security_crypto#279 -> @selo
  - treated deprecated declarations as errors: https://github.com/eclipse-score/inc_security_crypto/pull/279/changes#diff-544556920c45b42cbfe40159b082ce8af6bd929e492d076769226265f215832fR20-R26
  - This is needed for reference integration target and being a stable repo
  - all the errors so far are resolved.
- OpenSSL Provider: Support AES-CBC cipher, Random number and ECDSA inc_security_crypto#181 -> @prabakaranklst
- feat(cryptoki): multi-slot support, C_initialize optimization and token initialization improvements inc_security_crypto#276 -> @ShoroukRamzy
- - some more PR's for dependency and tooling updates.
Status of ongoing PR's ongoing (PRs arranged below in order of creation. Oldest being first)
1. Added POCs and Design Decision for IPC selection inc_security_crypto#169 -> @selo
  - Review completed. Rework completed. Re - review ongoing.
  - A brief look at the requirements that is being aimed by this migration: https://eclipse-score.github.io/inc_security_crypto/pr-169/score/crypto/src/ipc/message_passing_adapter/docs/requirements/requirements.html#functional-requirements
  - There are about 30 requirements.
  - All requirements are being implemented except: comp_req__ipc__inter_vm_communication and comp_req__ipc__cpp_rust_interoperability
    - Check for the "status" and "satisfied by" links are correctly depicted for these two requirements. To use "Valid from" field in the requirements. R. Sebastian.
  - There is a difference between communication wrt to timeout feature. in crypto timeout is implemented coming from safety violation but communication does not support this.
  - Shouldn't timeout be a central safety goal for all features? Check with Safety team (Attilio, Philipp,) R. Sunil
2. https://github.com/eclipse-score/inc_security_crypto/pull/197 -> @ChansAlive
  - Review + rework ongoing
  - The breakout session was done on Monday 12 Oct 2026 with Lazlo, Ugesh, Oliver, Athul and Sunil. Key summary points of the breakout:
    - Went through the changes and high-level discussion about the architectural changes that are being aimed at.
    - Additional design documents (static and/or dynamic views) would be helpful to get a better understanding of the full picture.
    - No logs are available. debugging is difficult. everything is console only but not in remote dlt. Point being checked. Remote backend logging to be added. To be discussed with reference integration topic.
    - Cross provider concept (ex. CSR signing with private key in PKCS11) was briefly discussed. But will be taken up after the ongoing certificate PR's are completed.
    - Mediator will be refactored into smaller meaningful ones (its already becoming big). along with the ideas taken over from Hashing PR from KS (autocrypt). This PR will be next PR after current daemon PR is completed and before API + Config PRs.
      ...
3. https://github.com/eclipse-score/inc_security_crypto/pull/199 -> @HeHa112
  - Review completed. Waiting for rework.
  - Re-basing with the latest changes
  - Checking on how to integrate KEM changes.
4. crypto: Migrate hash functionality from baselibs inc_security_crypto#237 -> @kssim
- Review completed. Rework completed. Re-review ongoing.
- Discussion about the next steps in Architecture community. As this is a cross-cutting topic with Baselib + Config management + Security. Meeting on [sdv-wg-SCORE] Architecture Community Monday 19, October 2:00 – 3:00pm CET
- Follow up improvement stories created:
  - Support application-scoped provider resource resolution: Support application-scoped provider resource resolution inc_security_crypto#290
  - Resolve and propagate the primary provider for key-slot resources: Resolve and propagate the primary provider for key-slot resources inc_security_crypto#291
1. [draft]: https://github.com/eclipse-score/inc_security_crypto/pull/250 -> @ChansAlive
  - To be taken up after point 2
  - Review ongoing from @GuruprasadBhatL
2. [draft]: https://github.com/eclipse-score/inc_security_crypto/pull/251-> @ChansAlive
  - To be taken up after point 2.
3. OpenSSL related topics -> @ShoroukRamzy
  1. OpenSSL movement: Move OpenSSL to a separate repo: Move OpenSSL to a separate repo inc_security_crypto#272
    - New repo for OpenSSL created: https://github.com/eclipse-score/openssl
    - PR created: https://github.com/eclipse-score/openssl/pull/1/changes
    - Dynamic files to be also created.
    - Add the recently seen improvement: etas-contrib/score_inc_security_crypto@44307ad
    - What kind of acceptance test do we need to for this repo? ex. when ever we do version update.
      - Update it as a patch in downstream repo. This repo we have only basic build related checks.
      - Run the tests in downstream repo ex Crypto and if successful, then it could be concluded that the update was successful. In long run ideally all these tests shall be executed and checked in reference integration. It may not be needed to test on Baselibs.
      - Check if we need to follow the module template for this repo. Also, what is followed for other similar OSS components in SCORE. Ex. Refer SCORE Crates on what is done. basic document, basic requirement, how is testing done..?? Check with SCORE Crates colleagues. R. Sunil
  2. Move OpenSSL -sys crate to score crate and use the above openssl: Migrate openssl-sys to score-crates and align version synchronization inc_security_crypto#183
    - PR created. feat: integrate openssl and openssl-sys crates in score crates score-crates#79

3. Update OpenSSL version in baselibs to the above openssl: https://github.com/eclipse-score/inc_security_crypto/issues/273
- PR created: https://github.com/eclipse-score/baselibs/pull/666
- Will be taken up after the OpenSSL PR (point 7.1) is closed.

      4. Will create another PR in Crypto to show the new dependencies. R. Shoruk

      5. Some more minor changes expected to resolve issues for reference integration. details will be shared offline. R. Shoruk

0 replies

sunildevda · 2026-10-20T10:57:52Z

sunildevda
Oct 20, 2026
Collaborator

21-Oct-26, 10-11 o'clock

Agenda:

[Organizational topic] Check participants
PR's closed since last meeting
Status of ongoing PR's
- User Interface Refactor inc_security_crypto#261 -> @prabakaranklst
Feedback/Update about the migration of hashing feature from Baselibs to Security Crypto

Participants:

Minutes:

PR's closed since last meeting:
- Added POCs and Design Decision for IPC selection inc_security_crypto#169 -> @selo
- automated dependency maintenance, covering CI workflows, Python dependencies, documentation tooling, coverage tooling, and the development container..
Status of ongoing PR's ongoing (PRs arranged below in order of creation. Oldest being first)
1. Certificate Management Daemon Component inc_security_crypto#197 -> @ChansAlive
  - 1st round of review + rework done.
  - Final minor rework and confirmation pending. once this is pushed a re-review will be done
  - Some more improvements task created under Basic Certificate Management features inc_security_crypto#161
2. iav_primula: add first integration dummy inc_security_crypto#199 -> @HeHa112
  - Rebase to the latest score main done.
  - Review completed. Final set of changes being done and will be mostly completed by tomorrow.
  - Re-review will be done by Athul
3. crypto: Migrate hash functionality from baselibs inc_security_crypto#237 -> @kssim
  - Review + rework completed.
  - Re-review to be taken up after the Cert management fix is done by Athul
  - Follow up improvement stories created:
    - Support application-scoped provider resource resolution: Support application-scoped provider resource resolution inc_security_crypto#290
    - Resolve and propagate the primary provider for key-slot resources: Resolve and propagate the primary provider for key-slot resources inc_security_crypto#291
4. [draft]: Add certificate management configuration parsing and tests inc_security_crypto#250 -> @ChansAlive
  - To be taken up after point 1
  - Review ongoing from @GuruprasadBhatL
5. [draft]: Implement certificate management API and daemon integration inc_security_crypto#251 -> @ChansAlive
  - To be taken up after point 1.
6. OpenSSL related topics -> @ShoroukRamzy
  a. OpenSSL movement: Move OpenSSL to a separate repo: https://github.com/eclipse-score/openssl/pull/1/changes
  - Review completed. Rework ongoing
  - downstream testing in score_crates, score_baseibs, inc_security_crypto shall be checked, to prove correctness of the changes.
  - central overwrite of openssl via label flag for C++ and Rust. Goal is to demo overwrite to bazel registry version in score_baselibs.
  - (opt-in dynamic feature) prepared for dynamic library done but more changes to be done to be make it usable. This is not needed to be solved for reference integration and can be done later as well.
  - New PR for Crypto to use this repo will be created soon.
  
  b. Move OpenSSL -sys crate to score crate and use the above openssl: Migrate openssl-sys to score-crates and align version synchronization inc_security_crypto#183
  - PR created. feat: integrate openssl and openssl-sys crates in score crates score-crates#79
  - Review completed. Rework ongoing.

c. Update OpenSSL version in baselibs to the above openssl: eclipse-score/baselibs#666
- Review completed. Rework is ongoing.

   - Following cleans to be also done for the reference integration objective. Will be taken up after the previous PRs are completed. changes are to be done in CryptoKi component.

d. (new) eclipse-score/inc_security_crypto#177
e. (new) eclipse-score/inc_security_crypto#178
f. (new) eclipse-score/inc_security_crypto#182

7. (new) https://github.com/eclipse-score/inc_security_crypto/pull/299 -> @GuruprasadBhatL
    - Single shot and streaming implementation are supported for all these new algorithm
    - Integration test currently covers minimum test combinations (ex. RSA 2k and 3k)
    - Prehashing mode will be set at context configuration. Algorithm will be independent of pre-hash option. this is done to avoid explosion of the algorithm surface with the different extension options https://github.com/eclipse-score/inc_security_crypto/pull/299/changes#diff-3cf6017507f1ddb0e0dc0b8ce85a61276d35799ee892f8e086930abc6f91411bR112-R115
    - Tradeoff of this approach: due to this same context can be reused for pre-hash mode and without hash mode. a new context has to be created for the different mode. 
    - Current opinion is better to go with this approach of keeping the algorithm names to minimum and all extensions to be handled via function parameters. 
    - How is prehashing for Ed25519 will be handled? To be checked offline R. Guru

8. (new) https://github.com/eclipse-score/inc_security_crypto/pull/311 -> @prabakaranklst
    - Sebastian will start the review

3. Feedback/Update about the migration of hashing feature from Baselibs to Security Crypto

Was presented in the architectural community. The migration plan was approved (timeline to be discussed). In general, the consensus was that Security Crypto is the right home for SHA algorithm support. https://github.com/orgs/eclipse-score/discussions/2457?sort=new#discussioncomment-18950407
Need to present the same in Tech board community as well.
Config management team was not present but discussion ongoing via emails. Config management would need a solution with ASIL level. and the migration plan will be revisited based on the discussion outcome.
There are also other internal users of Baselibs hashing in BMW (basically direct users of this functionality exist). Feedback about the migration expected from BMW colleagues.

Access control for Crypto - DR-003-ARCH-ACL-Concept: Generic Format for Access Control List #3058
- Topic will be continued to be discussed in architecture + communication team to look at the access control for the other areas in middle-ware
- For Crypto access control review findings, ETAS will provide the next set once the current configuration concept story is progressed
- There is no change in the last discussion about this topic for Crypto
- Last times pictures will be added to this meeting R. Christian

1 reply

christianbe9 Oct 21, 2026
Collaborator

sunildevda · 2026-10-27T13:35:38Z

sunildevda
Oct 27, 2026
Collaborator

28-Oct-26, 10-11 o'clock

Agenda:

[Organizational topic] Check participants
PR's closed since last meeting
Status of ongoing PR's
Feedback/Update about the migration of hashing feature from Baselibs to Security Crypto
Usage of IAV_Primula name in SCORE Crypto: iav_primula
Standalone PKCS11 crypto provider vs OpenSSL PKCS11 provider
New PRs for Import/Export of raw keys + pre-hashing for ECDSA P384-512 will be added (will be added soon)
PKCS11 Rust Crypto driver vs C++ implementation - (separate breakout)
Draft PR for LoLa migration

Participants:

Minutes:

PR's closed since last meeting:
- Remove IStreamingOutputContext and expose only Init() & Reset() from IStreamingContext inc_security_crypto#311 -> @prabakaranklst
- The remaining merged PRs (17 PRs) were routine Renovate/Dependabot updates to CI workflow revisions and SCORE dependencies, including score_devcontainer, score_bazel_cpp_toolchains, score_docs_as_code, score_process_description, and score_coverage...
Status of ongoing PR's ongoing (PRs arranged below in order of creation. Oldest being first)
2.1 Certificate Management Daemon Component inc_security_crypto#197 -> @ChansAlive
- Additional review points were received last week.
- Final minor rework and confirmation pending. Target is to close this soon.
- Final check will be done by Oliver. Will be merged soon. Volker will approve it.
- Recommendation to create small PRs (if possible) and create issues for new topics.
2.2 iav_primula: add first integration dummy inc_security_crypto#199 -> @HeHa112
- Review completed. Rework is completed.
- rebase might needed based on the order in which PRs are merged.
- Athul will have a final look and merge it
- Renaming of IAV_Primula will be done. could be renamed to pqc_provider (or something similar).
- Update the list of algorithms that will be supported in the Epic Cleanup IAV Primula for S-CORE usage inc_security_crypto#45
- Started work on Use the post-quantum algorithms from the PQCleanAutomotive repository inc_security_crypto#53
2.3 crypto: Migrate hash functionality from baselibs inc_security_crypto#237 -> @kssim
- Review + rework completed. Re-review ongoing.
- The PR for the baselibs can be closed. migration from Baselibs will be done separately (details below).
2.4 [draft]: Add certificate management configuration parsing and tests inc_security_crypto#250 -> @ChansAlive
- To be taken up after point 2.1
- Review done. Rework done.
- Will be rebased with latest changes and be opened for review by this week.
2.5 [draft]: Implement certificate management API and daemon integration inc_security_crypto#251 -> @ChansAlive
- To be taken up after point 2.1.
- First there will be a migrator refactoring PR and then this will be taken up.
2.6 Support Pre-hasing in already exisiting ECDSA, support for RSA,Ed25519 Sign and Verify inc_security_crypto#299 -> @GuruprasadBhatL
- Review completed. Rework ongoing.
- Known limitation to be updated on the length of the data
- Review points from Sebastian are addressed but open.
- Re-review form KS and Prabhakaran to be completed.
- Three options:
  - 1. alg id extended
  - 1. context config -> drawback bloating of config.
  - 1. set extended parameter api -> generic api with key value pair. This is already existing but is not wired in IPC yet.
- Use case is only for RSA. Option 3 could be best option. to be checked in the follow up task Support PKCS v1.5 padding for RSA digital signature inc_security_crypto#319
2.7 OpenSSL related topics -> @ShoroukRamzy
2.7.1 OpenSSL movement: Move OpenSSL to a separate repo: https://github.com/eclipse-score/openssl/pull/1/changes
- Review completed. Rework completed.
- Two new findings identified.
- Downstream testing in score_crates, score_baseibs, inc_security_crypto checked and working.
- To be checked if the changes are working in inc_security_crypto
- Once this is closed we need to update the opensll like done here: https://github.com/eclipse-score/bazel_registry/pull/526/changes and also have a responsible for this. Only committers can be responsible: Athul, Volker, Marcus. Create a PR for this.

2.7.2 Move OpenSSL -sys crate to score crate and use the above openssl:
- PR1: eclipse-score/score-crates#79
- Rework completed. Approved by Oliver.
- Approval from arkjedrz pending.
- Current usage of git_override to be removed once openSSL repo is made available (point 2.7.1 above)
- PR 2 (new): eclipse-score/score-crates#83

2.7.3 Update OpenSSL version in baselibs to the above openssl: eclipse-score/baselibs#666
- Review + rework completed.
- Current usage of git_override to be removed once openSSL repo is made available (point 2.7.1 above)

2.7.4 (new) eclipse-score/inc_security_crypto#317
- Review completed. Rework ongoing.

  2.7.5 New PRs for the topics we discussed last week will be created soon.

2.4 (new) eclipse-score/inc_security_crypto#326 -> @kssim
- Changes are done. there is an example of hashing can be done.
- Oliver will take up the review after the current IPC review task.

2.5 (new) https://github.com/eclipse-score/inc_security_crypto/pull/329 -> @prabakaranklst
   - Changes are done. improvements that were identified in the last signature PR
   - Athul will do the review. 
   - In general the idea is that for each family there will be one set of file created.

Feedback/Update about the migration of hashing feature from Baselibs to Security Crypto
- Discussion minutes with Config management + Baselibs team: https://github.com/orgs/eclipse-score/discussions/2311#discussion-9228456
- From the discussions, it basically comes down to fact that we need to have following three solutions:
  3.1 ASIL qualified lib only non FIPS compliant solution (which is what Baselibs offers currently. No dependency with OpenSSL) -> for Config management
  3.2 FIPS complaint QM Crypto API only solution (local crypto provider) -> for other existing BMW internal users
  3.3 FIPS compliant FFI Crypto API + QM Crypto daemon solution (which is what will be offered by Security Crypto) -> standard solution for all users
- Core architectural conclusion: Keep the ASIL solution in Baselibs and this will be the permanent home for a fully qualified lib only non FIPS ASIL solution. All other SHA384 and SHA512 to be offered from Security Crypto. Basically, from a SCORE middleware perspective, Security crypto will only offer FIPS complaint solution.
- Since we do not have local crypto provider solution yet, Baselib solution will not yet be depreciated. Once we have a working solution for local crypto provider (independent of fully quality level), we can then initiate the next migration steps of depreciation + removal from Baselibs.
- Following Epic + task for this use case created in security backlog:
  - Local crypto provider support inc_security_crypto#332
  - Concept for local crypto provider inc_security_crypto#15
  - Support of local crypto provider Hashing inc_security_crypto#333 -> for supporting hashing use cases first and then other key based use cases could be supported.
Usage of IAV_Primula name in SCORE Crypto: iav_primula
- As I understand from the SCORE the names should not contain company name or product names. should be vendor neutral. Not a legal expert so cant say with certainty. But more and more it looks like we should avoid using IAV and/or Primula in the component or provider names.
- https://wiki.eclipse.org/Naming_Conventions
- https://www.eclipse.org/projects/handbook/#starting-vendor-neutrality
- renaming planned under Check naming convention and vendor neutrality of iav_primula inc_security_crypto#338
Standalone PKCS11 crypto provider vs OpenSSL PKCS11 provider
- Two ways to access PKCS11 HSM library: 1. Via PKCS11 crypto provider and 2. Via OpenSSL (picture below).
- Advantage of standalone PKCS11 crypto provider:
  - Solution is independent of OpenSSL. For projects that does not want dependency and long term maintenance with OpenSSL
  - Any custom implementations or extensions in PKCS11 HSM/TEE library are easier as no changes in OpenSSL needed.
- Routing via OpenSSL is still possible in the current architecture and this is something how the provider gets integrated into the actual project.
- How will Cross provider concept work with CSR esp when the keys are stored in PKCS11 store?
PKCS11 Rust Crypto driver vs C++ implementation - (separate breakout)
- Athul, Oliver, Shoruk, Ugesh, Lazlo, Abdullah
- Breakout on next Monday or Tuesday. R. Sunil

0 replies

Eclipse S-CORE

Security & Crypto FT Meeting Minutes 2026 #2839

Uh oh!

Uh oh!

qor-lb Apr 27, 2026 Maintainer

Security Feature Team (FT) Overview

👥 Leadership & Ownership

Code Owners

💬 Communication

💻 Development Resources

📚 General S-CORE Resources

Replies: 29 comments · 7 replies

Uh oh!

Uh oh!

sunildevda May 5, 2026 Collaborator

Uh oh!

Uh oh!

sunildevda May 8, 2026 Collaborator

Uh oh!

Uh oh!

sunildevda May 11, 2026 Collaborator

Uh oh!

Uh oh!

sunildevda May 18, 2026 Collaborator

Uh oh!

Uh oh!

sunildevda May 27, 2026 Collaborator

Uh oh!

schreibwsag May 27, 2026

Uh oh!

Uh oh!

andilar Jun 3, 2026 Collaborator

Uh oh!

Uh oh!

sunildevda Jun 9, 2026 Collaborator

Uh oh!

andilar Jun 10, 2026 Collaborator

Uh oh!

Uh oh!

PandaeDo Jun 10, 2026 Collaborator

Uh oh!

Uh oh!

sunildevda Jun 16, 2026 Collaborator

Uh oh!

schreibwsag Jun 17, 2026

Uh oh!

Uh oh!

sunildevda Jun 17, 2026 Collaborator

Uh oh!

christianbe9 Jun 19, 2026 Collaborator

Uh oh!

Uh oh!

GuruprasadBhatL Jun 19, 2026 Collaborator

Uh oh!

christianbe9 Jun 22, 2026 Collaborator

Uh oh!

Uh oh!

sunildevda Jun 30, 2026 Collaborator

Uh oh!

Uh oh!

sunildevda Jul 7, 2026 Collaborator

Uh oh!

Uh oh!

sunildevda Jul 14, 2026 Collaborator

qor-lb
Apr 27, 2026
Maintainer

Replies: 29 comments 7 replies

sunildevda
May 5, 2026
Collaborator

sunildevda
May 8, 2026
Collaborator

sunildevda
May 11, 2026
Collaborator

sunildevda
May 18, 2026
Collaborator

sunildevda
May 27, 2026
Collaborator

schreibwsag
May 27, 2026

andilar
Jun 3, 2026
Collaborator

sunildevda
Jun 9, 2026
Collaborator

andilar Jun 10, 2026
Collaborator

PandaeDo Jun 10, 2026
Collaborator

sunildevda
Jun 16, 2026
Collaborator

schreibwsag
Jun 17, 2026

sunildevda
Jun 17, 2026
Collaborator

christianbe9 Jun 19, 2026
Collaborator

GuruprasadBhatL Jun 19, 2026
Collaborator

christianbe9 Jun 22, 2026
Collaborator

sunildevda
Jun 30, 2026
Collaborator

sunildevda
Jul 7, 2026
Collaborator

sunildevda
Jul 14, 2026
Collaborator