아이폰에서 웹페이지 링크를 홈화면에 등록하기
1. 싸파리 실행.
2. 링크용 유알엘로 이동
--> dam.kwater.or.kr
3. 아래쪽에 공유 아이콘 클릭
안드로이드에서 웹페이지 링크 홈화면에 등록하기.
1. 크롬 실행
2. 우상단의 점세개(메뉴 클릭)
3. '홈화면에 추가' 선택
4. 원하는 이름으로 변경
5. '추가'버튼 클릭하면 추가됨.
레지스트리 : HKEY_CURRENT_USER/Console 위치에 VirtualTerminalLevel 이란 이름으로 DWORD 값 1 추가
0기본값 0인데, Ansi 컬러 적용 안하는게 기본임.
Windows10 이상 커맨드에 적용 가능 확인함.
1. 인터넷에서 openssl download 검색 또는 웹 브라우저에서 아래 주소로 접속
https://sourceforge.net/projects/openssl/
(글 작성중인) 현재 2016년 9월 버전 압축파일 다운로드 가능
http://slproweb.com/products/Win32OpenSSL.html
32/64비트 설치프로그램 다운로드 가능.
2. 적당한 폴더에 압축 파일을 풀고 경로와 환경 파일을 시스템에 등록. 설치 프로그램으로 설치한 경우, 생략 가능.
path 추가 : C:\OpenSSL\bin
OpenSSL 환경파일을 시스템 환경변수에 추가
변수 명 : OPENSSL_CONF
변수 값 : C:\OpenSSL\bin\openssl.cnf
(새로 실행한) cmd에서 openssl version 실행
결과 : OpenSSL 1.0.2j-fips 26 Sep 2016
또는 : OpenSSL 3.0.1 14 Dec 2021 (Library: OpenSSL 3.0.1 14 Dec 2021)
3. RootKey (루트 인증서 키)파일 만들기
openssl ecparam -genkey -name prime256v1 -out rootca.key
ec : EC (Elliptic curve) key processing.
ecparam : EC parameter manipulation and generation.
-genkey :
This option will generate an EC private key using the specified parameters.
-name arg :
Use the EC parameters with the specified 'short' name.
Use -list_curves to get a list of all currently implemented EC parameters.
-out filename :
This specifies the output filename parameters to. Standard output is used if this option is not present. The output filename should not be the same as the input filename.
=> 포물선 키 프로세스 방식으로 키를 작성하는데 prime256v1 이라는 이름의 변수를 사용해서 rootca.key 파일을 생성함.
4. 인증 서명 요청서 (rootca.csr) 만들기
openssl req -new -sha256 -key rootca.key -out rootca.csr
req :
인증서 발급에 필요한 정보를 담고있는 '인증 서명 요청' 파일(csr) 생성. Root CA 인증서는 자기 자신 인증으로 만들 수 있음.
-new :
이 옵션은 새 인증서 요청을 생성합니다. 사용자에게 관련 필드 값을 묻는 메시지가 표시됩니다. 프롬프트된 실제 필드, 최대/최소 크기는 설정 파일 및 요구한 extension에 지정(저장)됩니다.
-key 옵션이 제공되지 않으면 구성 파일에 지정되거나 -newkey 및 -pkeyopt 옵션과 함께 제공된 정보를 사용하여 새 개인 키를 생성하고, 그렇지 않으면 기본적으로 2048비트 길이의 RSA 키를 생성합니다.
If the -key option is not given it will generate a new private key using information specified in the configuration file or given with the -newkey and -pkeyopt options, else by default an RSA key with 2048 bits length.
-sha256
-key filename | uri
이 옵션은 새 인증서 또는 인증서 요청에 서명하기 위한 개인 키를 제공합니다. -in을 지정하지 않으면 해당 공개 키가 새 인증서 또는 인증서 요청에 배치되어 자체 서명이 생성됩니다.
인증서 서명의 경우 이 옵션은 -CA 옵션으로 재정의(overridden)됩니다.
이 옵션은 PEM 형식 파일에 대한 PKCS#8 형식 개인 키도 허용합니다.
C:\src\PyTest\ssl>openssl req -new -sha256 -key rootca.key -out rootca.csr
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:KR
State or Province Name (full name) [Some-State]:Gyeonggi-do
Locality Name (eg, city) []:Seoul
Organization Name (eg, company) [Internet Widgits Pty Ltd]:MyCompany
Organizational Unit Name (eg, section) []:AIRnD
Common Name (e.g. server FQDN or YOUR name) []:MyCompany.co.kr
Email Address []:test@mycompany.co.kr
-----
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
C:\src\PyTest\ssl>
5. rootca.crt SSL 인증서 파일 만들기 (CA 루트 인증서)
openssl x509 -req -sha256 -days 999999 -in rootca.csr -signkey rootca.key -out rootca.crt
x509
X.509 Certificate Data Management.
이 명령은 다목적 인증서 처리 명령입니다. 인증서 정보를 인쇄하고, 인증서를 다양한 형식으로 변환하고, 인증서 신뢰 설정을 편집하고, 처음부터 인증서를 생성하거나 요청을 인증한 다음 자체 서명하거나 "마이크로 CA"처럼 서명하는 데 사용할 수 있습니다.
signkey : This option is an alias of -key.
key :
이 옵션은 새 인증서 또는 인증서 요청에 서명하기 위한 개인 키를 제공합니다. -force_pubkey를 지정하지 않으면 해당 공개 키가 새 인증서 또는 인증서 요청에 배치되어 자체 서명이 생성됩니다.
in :
이것은 -req 플래그가 사용되는 경우 인증서 요청을 읽기 위한 입력 파일 또는 인증서를 읽기 위한 입력을 지정합니다. 두 경우 모두 기본값은 표준 입력입니다.
이 옵션은 -new 플래그와 함께 사용할 수 없습니다.
6. 서버 키 만들기
openssl ecparam -out server.key -name prime256v1 -genkey
ec : EC (Elliptic curve) key processing.
ecparam : EC parameter manipulation and generation.
-genkey :
This option will generate an EC private key using the specified parameters.
-name arg :
Use the EC parameters with the specified 'short' name.
Use -list_curves to get a list of all currently implemented EC parameters.
-out filename :
This specifies the output filename parameters to. Standard output is used if this option is not present. The output filename should not be the same as the input filename.
=> 포물선 키 프로세스 방식으로 키를 작성하는데 prime256v1 이라는 이름의 변수를 사용해서 server.key 파일을 생성함.
7. 서버 인증 서명 요청서 만들기
openssl req -new -sha256 -key server.key -out server.csr
req :
인증서 발급에 필요한 정보를 담고있는 '인증 서명 요청' 파일(csr) 생성. Root CA 인증서는 자기 자신 인증으로 만들 수 있음.
8. 서버 인증서 만들고 자체 서명하기
openssl x509 -req -sha256 -days 999999 -in server.csr -CA rootca.crt -CAkey rootca.key -CAcreateserial -out server.crt
CA :
서명에 사용할 "CA" 인증서를 지정합니다. 존재하는 경우 이는 다음과 같이 "마이크로 CA"처럼 작동합니다. "CA" 인증서의 주체 이름은 새 인증서의 발급자 이름으로 배치되며, 그런 다음 아래에 설명된 대로 "CA" 키를 사용하여 서명됩니다.
이 옵션은 -key(또는 -signkey)와 함께 사용할 수 없습니다. 이 옵션은 일반적으로 CSR을 참조하는 -req 옵션과 결합됩니다. -req 옵션이 없으면 처음부터 인증서를 생성하는 -new 옵션이 제공되지 않는 한 입력은 기존 인증서여야 합니다.
CAkey
인증서에 서명할 CA 개인 키를 설정합니다. 개인 키는 -CA와 함께 제공된 인증서의 공개 키와 일치해야 합니다. 이 옵션이 제공되지 않으면 키가 -CA 입력에 있어야 합니다.
CAcreateserial
이 옵션을 사용하면 존재하지 않는 경우 CA 일련 번호 파일이 생성됩니다. 이 파일에는 일련 번호 "02"가 포함되고 서명되는 인증서의 일련 번호는 1입니다. -CA 옵션이 지정되고 일련 번호 파일이 존재하지 않으면 난수가 생성됩니다. 이것은 권장되는 방법입니다.
9. 서버 인증서 정보 확인하기
openssl x509 -in server.crt -text -noout
x509
X.509 Certificate Data Management.
이 명령은 다목적 인증서 처리 명령입니다. 인증서 정보를 인쇄하고, 인증서를 다양한 형식으로 변환하고, 인증서 신뢰 설정을 편집하고, 처음부터 인증서를 생성하거나 요청을 인증한 다음 자체 서명하거나 "마이크로 CA"처럼 서명하는 데 사용할 수 있습니다.
text
인증서를 텍스트 형식으로 인쇄합니다. 공개 키, 서명 알고리즘, 발급자 및 주체 이름, 일련 번호 존재하는 확장 및 신뢰 설정을 포함한 전체 세부 정보가 인쇄됩니다.
noout
이 옵션은 아래 옵션에서 요청한 인쇄 이외의 출력을 방지합니다.
10. 자체 서명된 루트 인증서를 개인 컴퓨터에 설치해서 서버 인증하기
11. 개인 키 cipher 변경
openssl rsa -in foo.pem -out foo_unencrypted.pem
rsa : RSA Keys 관련 명령 수행. 아웃 옵션에 따라 다양한 형태의 요소로 변환
in :
입력 파일 지정. 없으면, 표준입력이 지정됨. 키가 암호화 된 경우, 암호 구문을 입력하라는 메시지 표시됨
out :
키를 저장할 출력파일 지정. 없으면 표준 출력으로 지정됨. 암호 옵션이 설정되어있을 경우, 암호 입력 요청 메시지 표시. 입력파일명과 출력파일명은 달라야함.
-aes128, -aes192, -aes256, -aria128, -aria192, -aria256, -camellia128, -camellia192, -camellia256, -des, -des3, -idea
이 옵션들은 출력 전에, 개인키를, 지정 cipher로 암호화 함. 암호를 입력하라는 문구가 표시됨. cipher 옵션이 없으면, 암호 제거. 설정하면, 암호를 추가하거나 변경하기 위해 사용할 수 있음.
※※ (OCPP용) 클라이언트 인증서 작성 시,
subject 항목 설정할 때,
O(organizationName) RDN : 충전소 운영자 이름
CN(commonName) RDN : 충전소 Serial-Number
인증서 설치
HTTP 기본 인증(충전소 인증 참조)에 사용되는 비밀번호이든 CS 인증서이든, 각 CS를 CSMS에 인증하려면 고유한 자격 증명을 사용해야 합니다. 이러한 고유 자격 증명은 제조 또는 설치 중 어느 시점에서 충전 스테이션에 넣어야 합니다.
인증서 설치 요구사항
1. (권장)제조업체는 (충전기를)만들 때, 고유한 자격 증명(unique credentials)으로 충전소를 초기화(initialize)하는 것이 좋습니다.
2. 자격 증명은 암호화 난수 생성기(cryptographic random number generator)를 사용하여 생성하고, 안전한 환경에 설치해야 합니다(SHOULD).
3. (인증서는) CSO가 CSMS에서 요청할 때, 보안 채널을 통해 CSO로 보내져야 합니다(SHOULD). They SHOULD be sent to the CSO over a secure channel, so that the CSO can import them in the CSMS
4. 제조업체는 자체 인증서를 사용하여 서명할 수 있습니다(MAY).
5. 설치 후, CSO는 아래 두개의 섹션에서 설명된 방법을 사용하여, 자격 증명을 즉시 업데이트()할 것을 권장합니다.
A01 - HTTP 기본 인증을 위한 충전소 비밀번호 업데이트
A02 - CSMS 요청에 따라 충전소 인증서 업데이트
6. CSMS는 충전소가 사용할 수 있는 기능을 제한할 수 있습니다. CSMS는 BootNotification 상태인 Pending을 사용할 수 있습니다. 보류 중 상태에서 CSMS는 자격 증명을 업데이트할 수 있습니다.
p.s. CSMS(서버) - CS(클라이언트) 로 해석하면 일반적인 경우로 확대 해석 가능.
1. 모든 인증서는 아래문서(키 관리 권장사항)의 섹션 5.6.1에 따라 최소 112비트의 대칭 키와 동등한 보안을 제공하는 개인 키를 사용합니다(SHALL). 이것은 NIST가 2011-2030년 기간 동안 권장하는 키 크기입니다.
National Institute of Standards and Technology. Special Publication 800-57 Part 1 Rev. 4, Recommendation for Key Management. January 2016. https://csrc.nist.gov/publications/detail/sp/800-57-part-1/rev-4/final
2. 1번 내용 중, RSA 또는 DSA 적용 조건에서, 키는 최소 2048비트 길이로 변환됩니다.
3. 1번 내용 중, elliptic curve cryptography(타원곡선 암호화)적용 조건에서, 키는 최소 224비트 길이로 변환됩니다.
4. 모든 암호화 작업은, 미래 시스템에적합한, 아래문서에서 BSI가 권장하는 알고리즘만을 사용해야 합니다(SHALL). 이 규정에는, 인증서 계층 구조의, 인증서 서명을 포함합니다.
Bundesamt für Sicherheit in der Informationstechnik: Anwendungshinweise und Interpretationen zum Schema, AIS 20, Funktionalitätsklassen und Evaluationsmethodologie für deterministische Zufallszahlengeneratoren, Version 3.0, Bonn, Germany, May 2013. (in German) https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Zertifizierung/Interpretationen/AIS_20_pdf.html
5. 인증 기관(CA: Certificate Authority)의 서명에는 RSA-PSS 또는 ECDSA를 사용해야 합니다(SHOULD).
6. 해시 값을 계산하려면 SHA256 알고리즘을 사용해야 합니다(SHOULD).
7. 인증서는 PEM(Privacy-Enhanced Mail) 형식으로 인코딩된 X.509 형식으로 저장 및 전송되어야 합니다(SHALL).
8. 모든 인증서에는 serial-number가 포함되어야 합니다(SHALL).
9. 인증서 subject 필드에 있는 O(organizationName) RDN(Relative Distinguished Name : 상대 고유 식별명)에, 인증서 소유자의 회사명(organization name)을 써(contain)야 합니다(SHALL).
10. CSMS 인증서의 경우, subject 필드는 CN(commonName) RDN에, 서버단의 FQDN(Fully Qualified Domain Name : 도메인명)을 포함해야 합니다(SHALL).
11. CS 인증서의 경우, subject 필드는 CS의 고유한 serial-number로 구성된 CN(commonName) RDN을 포함해야 합니다(SHALL). 이 일련 번호는 URL 또는 IP 주소 형식이 아니므로 충전소 인증서가 CSMS 인증서와 구별될 수 있습니다.
참고: RFC 2818에, dnsName 형식의 subjectAltName extension이 있으면, 그것을 ID로 사용해야 한다고 되어있습니다. 이 규정은 OCPP 및 ISO 15118과는 맞지 않습니다. 즉, CS 및 CSMS 인증서에 사용해서는 안 됩니다(SHOULD NOT).
CSMS에 도달할 여러 네트워크 경로가 있는 경우 CSMS에 대해 dnsName 형식의 subjectAltName extension을 사용할 수 있습니다.
(예를들면, 사설 APN + (VPN에서 자신의 IP 주소를 사용하는) VPN의 경우, 그리고, 명명된 URL을 사용하는 공용 인터넷의 경우 등)
12. 모든 인증서는, X.509 Key Usage extension를 사용하여, 등록된 목적으로만 사용하도록 제한해야 합니다(SHOULD).
13. CS 인증서가 ISO 15118 프로토콜의 SECC 인증서로도 사용되는 경우 인증서는 ISO15118-2의 요구 사항도 충족해야 합니다(SHOULD).
14. 모든 인증서는, ISO 15118 표준과 호환되도록, X.509 확장 Key Usage extension을 사용하지 않는 것을 강력히 권장합니다. 다른 메커니즘으로 대체할 수 있습니다.
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)
