Great video! Are the generated access rights that are linked to a user role encoded in the ECU (i.e. is the user role state machine encoded in the ECU)? Or is it all part of the PKI certificate (including what services this user will be given access to)?
Just one comment on slide 2. SecOC does not provide encryption. Instead it provides integrity of data. We can say that it makes use of encryption algorithms to generate the MAC, but the data itself is sent in plaintext.
thanks for the nice presentation :) it really helps to know why on top of having Service 0x27, we need 0x29!- i was surprised to know, Authentication still exists even when session had changed. is this service applicable in BOOT mode or only in application ?
Glad you found it useful! The FBL can implement Authentication, this comes at the cost of increased FBL footprint (as it will need to 'carry' the needed functions).
This depends wholly on the design of the security mechanisms, for example, in our demo we use a 128-bit (16 byte) challenge, while ISO 14229-1 gives an example of a 256-bit (32 byte) challenge.
Please contact your local Vector office! They will be pleased to run through the presentation with you, and also help you with any project-specific questions that you may have: vector.com/contact
Thank you! The chain of trust is defined by the manufacturer, and so it's not possible to give an answer without knowing the specific details of a project - sorry!
How do you protect the FBL? As the FBL does the actual memory write before the application layer AUTOSAR services are available. The FBL cannot use the tester certificate to authenticate to tester access.
The FBL can implement Authentication, this comes at the cost of increased FBL footprint (as it will need to 'carry' the needed functions, and drivers, e.g. if an HTA is in use). This means it's very important to know about any possible Authentication requirements very early, to make sure an appropriately sized microcontroller is used!
Why are you saying that symmetric algorithm is very simple and not secure??? Thats not true. It has nothimg to do with flipping bits. The difference between sym and asym in regards to power is only that in the sym crypto you have only one shared secret, but in the asymmetric you have priv/pub key. However thank you for that video
Hi, we're sorry that the video isn't clear here: Iain was trying to say that with Security Access there is no requirement (or recommendation) as to the complexity of the shared secret (algorithm), and so it would be valid (yet also totally stupid!) to just have the shared secret to be flipping a bit or reversing the bit order. In the case of the new Authentication service, ISO14229-1 makes some 'recommendations' for suitable algorithms (based on ISO/IEC 9798-3).
I like your Videos,
Specially it helped me in many things in Continental and in many other companies,
Thank you Sir.
Sincerly Micheal.
Such a great explanation. Thank you!
Thanks for the insightful session.
Great Video!! but where can we get the information about the different sub functions of 29 service?
Very helpful, could you please explain the context of Ephemeral Diffie-Hellman key agreement as part of 0x29?
Great video! Are the generated access rights that are linked to a user role encoded in the ECU (i.e. is the user role state machine encoded in the ECU)? Or is it all part of the PKI certificate (including what services this user will be given access to)?
Daimler has this architecture of Private keys and certificates like Supplier, Factory etc
Just one comment on slide 2. SecOC does not provide encryption. Instead it provides integrity of data. We can say that it makes use of encryption algorithms to generate the MAC, but the data itself is sent in plaintext.
How the ECU is verifying the signature of the sender (in the public key certificate) ?
Thank you for impressive video! Is there any specific module which cares authentication on MICROSAR? Is it the Security manager?
APCE is covered by the DCM, the Security Manager is a PC application that Vector Tools can use to perform security tasks, such as APCE.
thanks for the nice presentation :) it really helps to know why on top of having Service 0x27, we need 0x29!- i was surprised to know, Authentication still exists even when session had changed.
is this service applicable in BOOT mode or only in application ?
Glad you found it useful! The FBL can implement Authentication, this comes at the cost of increased FBL footprint (as it will need to 'carry' the needed functions).
@@vectorinformatik thanks for your response and clarification dear Vector
What's the challenge data length from ECU to verify tester certificate?
This depends wholly on the design of the security mechanisms, for example, in our demo we use a 128-bit (16 byte) challenge, while ISO 14229-1 gives an example of a 256-bit (32 byte) challenge.
Can you check Service 29 with Diva?
Yes 😄
Where can I get the presentation for this video
Please contact your local Vector office! They will be pleased to run through the presentation with you, and also help you with any project-specific questions that you may have: vector.com/contact
This video is really informative. Just one question, how to get to know which all the certificates are required for the authentication service(29)?
Thank you! The chain of trust is defined by the manufacturer, and so it's not possible to give an answer without knowing the specific details of a project - sorry!
How do you protect the FBL? As the FBL does the actual memory write before the application layer AUTOSAR services are available. The FBL cannot use the tester certificate to authenticate to tester access.
The FBL can implement Authentication, this comes at the cost of increased FBL footprint (as it will need to 'carry' the needed functions, and drivers, e.g. if an HTA is in use). This means it's very important to know about any possible Authentication requirements very early, to make sure an appropriately sized microcontroller is used!
Why are you saying that symmetric algorithm is very simple and not secure??? Thats not true. It has nothimg to do with flipping bits. The difference between sym and asym in regards to power is only that in the sym crypto you have only one shared secret, but in the asymmetric you have priv/pub key. However thank you for that video
Hi, we're sorry that the video isn't clear here: Iain was trying to say that with Security Access there is no requirement (or recommendation) as to the complexity of the shared secret (algorithm), and so it would be valid (yet also totally stupid!) to just have the shared secret to be flipping a bit or reversing the bit order. In the case of the new Authentication service, ISO14229-1 makes some 'recommendations' for suitable algorithms (based on ISO/IEC 9798-3).