강의 순서 추천 부탁드려요

안녕하세요, 강의를 수강해주셔서 감사합니다.제가 정확한 직무와 제품군을 몰라 순서를 추천하기는 모호하여 아래와 같이 간략하게 나마 보안 관련된 강의들의 포인트들 남깁니다. 자동차 사이버 보안 - 자동차에 들어가는 실제 기능들을 소개하며, 기초적인 보안 알고리즘을 학습하실 수 있습니다.ASPICE - 보안 기능 개발자라고 하더라도 개발을 위한 프로세스를 알아야 제대로 된 개발을 하실 수 있습니다. 차량 업계의 개발 프로세스 표준을 다룹니다.TARA - 기능 개발 전 제품을 디자인 하는 단계에서 발생할 수 있는 취약점을 분석하고 이를 해결하는 방법론에 대해 다룹니다. TARA를 잘하면 보안 취약점을 많이 개선한 제품을 개발할 수 있습니다.VTA - 보안 기능 개발 및 프로세스를 기반으로 제품이 만들어졌다면 자동차에 제품을 탑재하여 판매를 해야합니다. 그치만, 무작정 판매할 수 있는 것은 아니고 보안적으로 안전한지 국가로부터 인증을 받아야 합니다. 이를 VTA라고 하며 해당 과정을 다룹니다. 우선 보안 관련 강의는 크게 위 4가지로 줄일 수 있는데, 도움이 되셨으면 좋겠습니다. 면접에서 좋은 결과 있었으면 합니다!

Secure Access 요약부분

안녕하세요, 질문해주셔서 감사합니다. 1.'SEED값'을 대칭키 알고리즘을 사용하여 암호화되어 전달된다라고 이해했는데 맞게 이해한걸까요?네, 맞습니다. 하지만 반드시 그런것은 아니다라고 말씀드리고 싶습니다. 그 이유는 고객 사양마다 다르고 꼭 대칭키 알고리즘을 사용하는 것도 아니며, 특정 프로젝트에서는 OEM에서 지정한 패턴(?) 규칙(?) 으로 하기도 하더라구요.,. 제가 설명드린 부분에 있어서는 이해하신 부분이 맞습니다. 2.암호화된 SEED값이 하위 ECU에게 보내지는건데, 그 과정에서 "ClientSendKey"라고 되어있는건 그 암호화된 데이터가 Key가 되어서 전달되는건가요? 아니면 암호화된 데이터 자체를 key라고 지칭하는건가요? 우선 통상적으로 보안적인 측면에서 KEY는 암호화 할 때 사용하는 KEY를 의미합니다. 하지만, $27 Service에서 'ClientSendKey' 암호화된 데이터가 key를 의미하게 됩니다. 말씀을 듣고 생각해보니, 사실 문서에는 'clientsendkey'라고 되어있지만, 왜 굳이 헷갈리게 key라고 했는지 의아하긴 하네요. 감사합니다.

PnC를 위한 인증서 관련 문의

안녕하세요, 질문 주셔서 감사합니다.root인증서는 주로 공유되지 않습니다. 계약 인증서를 받으면 cpo나 cps에서 해당 계약 인증서, 즉 leaf인증서인 계약 인증서에 대한 데이터가 백엔드에 위치하는지 안하는지를 통해 검사합니다. ( evse가 v2g를 소유하고 있는 것보다는 cpo나 cps쪽에서 소유하는 것이 맞다고 봅니다. )root인증서는 self-signed로 되어 trust anchor로서의 작용을 하게 됩니다. 이 때문에 각 인증서 체인에 대한 것을 신뢰해주지 서로 다른 root와의 연관성은 없습니다.MO Root인증서는 secc, cpo가 소유하며 계약 인증서 생성시 MO root를 주는 것이 아니라 서명만 하게 됩니다.혹시 더 궁금하신점 있으시면 말씀해주세요!

$36 Service Transfer Data Recovery Mechanism & padding byte

안녕하세요, 강의를 수강해주셔서 감사합니다.recovery mechanism? 우선 따로 recovery를 어떻게 해라 라는 말이 따로 기재되어 있지 않습니다. 하지만, TIER 1 제조업체에서는 NRC를 받고 ECU가 데이터를 제대로 수신받지 못하였을 때, 따로 recovery mechanism을 수행하는 것으로 알고 있습니다. ( 예를 들어, 특정 블록을 받지 못하여 NRC를 내보냈을 때, 해당 블록을 다시 보냄 ) padding? ISO-TP를 기반으로 0xFF의 패딩 값을 사용합니다. 0xCC는 보지 못하였습니다. 궁금하신 점 있으시면 편하게 물어봐주세요. 감사합니다 !

자동차 프로세스와 ASPICE 프로세스는 어떤점이 다른가요..?

안녕하세요, 강의를 수강해주셔서 감사합니다.우선 model fix의 경우는 차량에서 아키텍쳐를 정의하는 단계로 요구사항 정의 및 아키텍쳐 설계에 대항 것으로 볼 수 있습니다. 이에 따라 sys, swe의 각 단계에서 수행되는 것이라 볼 수 있습니다.proto는 시제품을 만드는 것이기에 요구사항을 기반으로 요구사항 구현 및 test에 포함되는 것이고 이 또한 sys,swe에 맵핑됩니다.마찬가지로 mp, sop 는 integration test, hardening test가 포함될텐데 이 또한 강의에서 sys, swe에 각각 포함됩니다.이처럼 각 과정들이 수행되며 sys, swe의 각 단계별로 이를 포함하고 있다고 생각하시면 됩니다. 각 산출물 또한 포함됩니다.

A-SPICE라는 것은...?

OEM이 CL 몇을 받아오라고 TIER1, TIER2에게 수주 받을 때 요구를 합니다. 그러면 TIER1, TIER2 는 ASPICE 심사원에게 심사를 받아 OEM에게 제출합니다. 이때 요구 받은 등급을 받을 때까지 수행해야 합니다. 또한, OEM도 전장 제품이기 때문에 ASPICE를 수행해야합니다.

Routine Control Negative Response 질문입니다.

안녕하세요, 강의를 수강해주셔서 감사합니다.강의에 잘못된 부분이 있네요, 7F 31 (NRC) 이런식으로 되는것이 맞습니다.제대로 이해하신거 같은데, 잘못된 정보를 전달드렸네요,, 수정하겠습니다. 피드백 감사합니다.

Application -> Bootloader jump

설계하기 나름이겠지만, 일반적으로는 programming session의 요청을 받으면 flag를 세우고, soft reset 후, flag가 있을 경우 bootloader에서 동작하도록 구현하곤 합니다.

Secondary Bootloader와 first bootloader

안녕하세요, 강의를 수강해주셔서 감사합니다.Secondary Bootloader는 기본 제품에 탑재되어 있는 것은 아니며, SWDL를 할 때 Secondary Bootloader를 다운 받게 됩니다. 보통 ram에다가 해당 데이터를 올려 사용하여, 다운로드 과정 중 전원이 꺼지면 다시 Secondary bootloader를 다운 받아야합니다.추가 질문 사항 있으시면 말씀해주세요 :)

realtime OS에 대한 궁금한점이 있어 연락드립니다.

안녕하세요 아구러푸님 !RTOS의 이상적인 동작은 설계자가 정한 시간 내에 태스크 처리 및 실행이 완료되는 것이 맞습니다. 그래서 처리시간보다 여유롭게 스케줄링 해놓습니다. 하지만 제품이 동작할 때 늘 정해진 task 내에 일을 처리하지 못할 수도 있습니다. ( 여러 동작들이 한꺼번에 와서 일을 정해진 시간 내에 못 끝내는등) 이 경우에는 task가 밀리게 됩니다. -> 누가 먼저 시작할지 교통정리가 필요할 것입니다. 이에따라, RTOS에서는 preemptive scheduling이라고 하여 각 task의 우선순위를 설정하여 매핑합니다. 또한 우선순위가 높은 task가 먼저 선점하여 처리되게 됩니다. 만약 질문해주신거처럼 중요한 task가 처리중에 다른 task가 치고들어오면 문제가 될것입니다. 그렇기 때문에 스케줄링은 중요하며, 만약 위 같이 중요한 task의 우선순위를 제일 높여 처리가 끝날때까지 선점할 수 있도록 구현할 수 있을거 같습니다. 추가적으로 질문있으시면 남겨주세요 !행복하고 좋은 하루 되세요 ㅎ 감사합니다