2022년 2월 8일 화요일

OCPP2.0.1, Security - 1.3.7 TLS with Client Side Certificates - Requirements (번역)

OCPP 2.0.1 Secure lv3. Requirements 

p.s. CSMS(서버) - CS(클라이언트) 로 해석하면 일반적인 경우로 확대 해석 가능.

1. 충전소(CS : Charging Station, client)CS 인증서로 CSMS(Charging Station Management System, server)에 자신을 인증해야 합니다.

2. CS 인증서는 TLS(전송 계층 보안 : Transport Layer Security) client 측 인증서로 사용되어야 합니다.

3. CSMS는 아래 RFC5280 문서의 6절에 설정된 경로 검증 규칙에 따라 충전소 인증서의 인증 경로를 검증해야 합니다. 

인터넷 X.509 공개 키 기반 구조 인증서 및 CRL(인증서 해지 목록) 프로필 : Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, Internet Engineering Task Force, Request for Comments 5280, May 2008, http://www.ietf.org/rfc/rfc5280.txt

4. CSMS는 인증서의 subject 필드에 있는 O(organizationName) RDN(Relative Distinguished Name : 상대 고유 식별명)에, CSO(Charging Station Operator : 충전소 운영자) 이름이 포함되어 있는지 확인하여, 인증서가 CSO(또는 CSO가 신뢰하는 조직)의 소유인지 확인해야 합니다.

5. CSMS는 인증서의 subject 필드에 있는 CN(commonName) RDN에, 충전소 고유 serial-number 가 포함되어 있는지 확인하여, 인증서가 이 충전소용인지 확인해야 합니다(인증서 속성 참조).

6. CSO가 충전소 인증서를 소유하지 않은 경우(예: 설치 직후)엔, 충전 스테이션과 계속 통신하기 전에 인증서를 업데이트하는 것이 좋습니다(설치 참조).

7. 충전소에 유효한 인증서가 없거나 인증 경로가 잘못된 경우, CSMS는 연결을 종료해야 합니다.

8. 7번이 발생하면, CSMS에 보안 이벤트를 기록하는 것이 좋습니다.

9. CSMS는 TLS 서버로 작동해야 합니다(SHALL).

10. CSMS는 CSMS 인증서를 서버 측 인증서로 사용하여 자신을 인증해야 합니다.

11. 충전소는 RFC5280 문서의 6절에 설정된 경로 유효성 검사 규칙에 따라 CSMS 인증서의 인증 경로를 확인해야 합니다.

12. 충전소는 commonName이 CSMS의 FQDN(Fully Qualified Domain Name : 도메인명) 과 일치하는지 확인해야 합니다.

13. CSMS가 유효한 인증서를 소유하지 않거나 인증 경로가 잘못된 경우, 충전소는 InvalidCsmsCertificate 보안 이벤트를 트리거해야 합니다(보안 이벤트의 전체 목록은 2부 부록 참조).

14. 13번이 발생하면, 충전소는 연결을 종료해야 합니다.

15. 통신 채널은 TLS를 사용하여 보호되어야 합니다(SHALL).

16. 충전소 및 CSMS는 TLS v1.2 이상만 사용합니다(SHALL).

17. 양 끝단 모두, 사용된 TLS 버전을 확인 해야 합니다.(SHALL)

18. 17에서 CSMS는, 충전소가 이전 버전의 TLS용 연결만 허용하거나, SSL만 허용함을 감지하면, CSMS는 연결을 종료해야 합니다.

19. 17에서 충전소는, CSMS가 이전 버전의 TLS용 연결만 허용하거나, SSL만 허용함을 감지하면, 충전소는 InvalidTLSVersion 보안 이벤트를 트리거하고 연결을 종료해야 합니다(보안 이벤트의 전체 목록은 2부 부록 참조).

20. TLS는 수정 없이, 위의 TLS Protocol 또는 그 후속 표준과 같이 구현되어야 합니다(SHALL).

The Transport Layer Security (TLS) Protocol Version 1.2, Internet Engineering Task Force, Request for Comments 5246, August 2008, http://www.ietf.org/rfc/rfc5246.txt

21. CSMS는 최소 아래의 cipher suit를 지원해야 합니다.

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

TLS_RSA_WITH_AES_128_GCM_SHA256 

TLS_RSA_WITH_AES_256_GCM_SHA384

참고: CSMS는 두 암호 제품군을 모두 지원하기 위해 2개의 다른 인증서를 제공해야 합니다. 또한 보안 프로필 3을 사용할 때 CSMS는 두 암호 제품군에 대한 클라이언트 측 인증서를 생성할 수 있어야 합니다.

22. 충전소는 아래중 한줄의 cipher suit를 지원해야 합니다.

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 와 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

TLS_RSA_WITH_AES_128_GCM_SHA256 와 TLS_RSA_WITH_AES_256_GCM_SHA384

참고 1: TLS_RSA는 순방향 보안을 지원하지 않으므로 TLS_ECDHE가 권장됩니다. 또한 충전소가 안전하지 않은 알고리즘 사용을 감지하면 InvalidTLSCipherSuite 보안 이벤트를 트리거해야 합니다(SHOULD)(보안 이벤트의 전체 목록은 2부 부록 참조).

참고 2: ISO15118-2는 EV와 충전 사이의 통신을 위해 다음 암호 제품군을 구현하도록 규정하고 있습니다.

TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256

23.  충전소와 CSMS는 아래 문서(ENISA Algorithms report)에서, 레거시 사용에 적합하지 않은 것으로 표시된, 암호화 기본 형식을 사용하는 암호 제품군을 사용하지 않아야 합니다. 이것은 이 사양에 설명된 하나(또는 그 이상)의 암호 제품군이, 레거시 사용에 부적합한 것으로 표시되면 더 이상 사용하지 않아야 함을 의미합니다.

ENISA European Network and Information Security Agency, Algorithms, key size and parameters report 2014, 2014. (last accessed on 17 January 2016) https://www.enisa.europa.eu/publications/algorithms-key-size-and-parametersreport-2014

24.  TLS 서버 및 클라이언트는 아래 RFC3749의 섹션 6에 설명된 대로 압축 side-channel 공격을 피하고 상호 운용성을 보장하기 위해, TLS 압축 방법을 사용하지 않아야 합니다.

Hollenbeck, S., "Transport Layer Security Protocol Compression Methods", RFC 3749, May 2004. https://www.ietf.org/rfc/rfc3749.txt 

25. 24번에서 CSMS가 충전소가 이러한 제품군 중 하나를 사용하는 연결만 허용한다는 것을 감지하는 경우, CSMS는 연결을 종료해야 합니다.

26. 24번에서 충전소는 CSMS가 이러한 제품군 중 하나를 사용하는 연결만 허용함을 감지하는 경우, 충전소는 InvalidTLSCipherSuite 보안 이벤트를 트리거하고 연결을 종료해야 합니다(보안 이벤트의 전체 목록은 2부 부록 참조).

27. 각 충전소에 대해 고유한 충전소 인증서를 사용해야 합니다(SHALL).

28. 충전소 인증서는 충전소와 전기 자동차 간의 TLS 연결을 설정하는 데 사용되는 ISO15118-2의 SECC 인증서와 동일한 인증서일 수 있습니다(MAY).

[ISO15118-2] Road vehicles – Vehicle to grid communication interface – Part 2: Technical protocol description and Open Systems Interconnection (OSI) layer requirements, Document Identifier: 69/216/CDV. https://webstore.iec.ch/publication/9273 



원본 출처 : OCA OCPP 2.0.1 part2 Specification (2020-03-31)

댓글 없음: