IoT 보안 기본 사항 - 1부 | 암호화 사용

작성자: Stephen Evanczuk

DigiKey 북미 편집자 제공

2020-06-03

편집자 주: 여러 단원으로 구성된 이 시리즈에서는 개발자가 시작 단계부터 모범 사례를 따르도록 도와주는 실용적인 지침을 제공합니다. 본 1부에서는 보안 설계의 기반이 되는 암호화 알고리즘에 대해 설명합니다. 2부에서는 보안 시스템에서 개인 키, 키 관리 및 보안 스토리지의 역할에 대해 설명합니다. 3부에서는 IoT 장치에서 시스템 및 응용 소프트웨어 실행을 훼손하려고 고안된 위협을 완화하기 위해 보안 프로세서를 기반으로 구축된 메커니즘을 살펴봅니다. 4부에서는 고급 프로세서에 보안 메커니즘을 적용하여 IoT 장치의 런타임 환경에서 공격을 완화하는 데 필요한 분리 상태를 보장하는 방법을 확인하고 보여줍니다. 5부에서는 IoT 장치를 IoT 클라우드 리소스에 연결하는 데 사용되는 고수준 보안 대책을 통해 IoT 장치에서 IoT 보안이 지속되는 방법에 대해 설명합니다.

산업, 의료, 교통 및 기타 중요 응용 분야에서 IoT 응용 제품에 대한 의존성이 빠르게 증가하면서 보안 환경이 획기적으로 변화했습니다. 이전 엔터프라이즈 응용 제품에서는 보안 알고리즘을 처리하기 위해 쉽게 구할 수 있는 리소스를 활용했습니다. 이와 달리 엔터프라이즈급 IoT 응용 제품에서는 리소스 제약이 있는 IoT 장치의 네트워크가 확대되고 이를 타겟으로 한 위협이 커짐에 따라 취약성이 발견되었습니다. 빠르게 부상하고 있는 IoT 기회에 대응하는 데 급급하다보니 조직에서는 저장된 데이터를 보호하고 취약한 네트워크를 통해 교환되는 데이터 및 명령을 보호하는 기본적인 보안 조치도 지원할 수 없는 기능적으로 부족한 IoT 장치를 배포하는 경우가 너무 많습니다.

물론 개발자가 설계를 보호하기 위해 해야 할 일은 다양한 요소에 따라 달라집니다. 응용 제품마다 위협이 존재하므로 위협에 따른 위험성을 적절히 평가해야 합니다. 장치가 연결되면 훨씬 더 많은 위협이 존재하므로 모든 IoT에는 최소한의 보안 조치가 필요합니다.

누군가에게는 간단한 IoT 장치에 강력한 보안 조치를 구현하는 것이 오버엔지니어링처럼 보일 수도 있지만, 아무리 간단한 온도 센서라도 충분히 보호되지 않는다면 해커가 회사 네트워크에 침입할 빌미를 제공하게 될 수 있습니다^[1]. 실제로 IoT 보안은 다방면에서 연결되는 IoT 응용 제품과 이러한 응용 제품의 기반이 되는 리소스가 제한된 장치로 인해 끊임없이 문제에 직면합니다. 소프트웨어에서 암호화 알고리즘을 실행하는 데 충분한 리소스를 갖춘 IoT 장치 설계에서도, 알고리즘을 구현하는 중에 발생하는 사소한 오류로 인한 응용 제품의 취약성은 그대로 남아 있습니다.

이 기사에서는 기본적인 암호화 알고리즘에 대해 설명하고 보안에서 암호화 알고리즘의 역할을 살펴봅니다. 그런 다음 개발자가 구현을 간소화하면서 보안의 다양한 측면을 개선하여 이러한 알고리즘을 가속화하도록 고안된 Maxim Integrated, Microchip Technology 및 Texas Instruments의 프로세서 및 특수 장치를 활용할 수 있는 방법을 보여줍니다.

다양한 유형의 암호화 알고리즘과 역할

암호화 알고리즘은 기본 보안 원칙인 기밀성, 인증(메시지의 출처 확인), 부인 방지(보낸 사람이 암호화되거나 서명된 메시지를 작성했는지 검증) 및 무결성을 규정하는 세 가지 광범위한 범주에 속합니다.

대칭 키 알고리즘: 알고리즘 또는 암호화에서 동일한 보안 키를 사용하여 사람이 읽을 수 있는(일반 텍스트) 메시지를 보호된 버전(암호 텍스트)으로 암호화하고, 나중에 암호 텍스트를 일반 텍스트로 다시 암호 해독합니다. 대칭 키 암호화는 일반적으로 기밀성을 확인하는 데 사용됩니다. 일반 대칭 암호화 알고리즘은 다음과 같습니다.
- 3중 데이터 암호화 표준(DES): 3DES라고도 하며 U.S. NIST(National Institute of Standards and Technology)의 공식 명칭은 3중 데이터 암호화 알고리즘(TDEA)입니다.
- 고급 암호화 표준(AES)^[2]: 256비트 키를 사용하는 알고리즘(예: AES-256)
비대칭 키 알고리즘: 이 암호화에서는 일반적으로 키 계약 및 디지털 서명을 위한 더 포괄적인 보안 프로토콜의 일부로, 연결된 개인 키 및 공용 키 세트를 사용하여 메시지를 암호화 및 암호 해독합니다. 비대칭 암호화는 일반적으로 기밀성, 인증 또는 부인 방지를 확인하는 데 사용됩니다. 공용 키 암호화 알고리즘은 다음과 같습니다.
- 유한 필드 암호화(FFC)를 사용하는 알고리즘:
  - FIPS(Federal Information Processing Standard) 디지털 서명 알고리즘(DSA)
  - IETF(Internet Engineering Task Force) 디피-헬먼(DH)^[3]키 교환
- 소인수 분해 암호화(IFC)를 사용하는 알고리즘:
  - RSA(Rivest–Shamir–Adleman)^[4]알고리즘
- 타원 곡선 암호화(ECC)를 사용하는 알고리즘:
  - 타원 곡선 디피-헬먼(ECDH)^[5]키 교환
  - 타원 곡선 디지털 서명 알고리즘(ECDSA)^[6]
해시 알고리즘: 이 알고리즘에서는 원래 메시지를 해시, 다이제스트, 서명 등 다양한 명칭으로 불리는 훨씬 작고 고유한 고정 길이 값으로 축소합니다. 이 단방향 변환 기능은 메시지가 변경되지 않았는지 확인하는 데 중요한 역할을 하며(무결성) 메시지 인증 코드(MAC), 키 지정 해시 메시지 인증 코드(HMAC), 키 유도 함수(KDF) 등 다양한 프로토콜에서 응용 제품을 찾습니다. 암호화 해시 알고리즘은 다음과 같습니다.
- 메시지 다이제스트 5(MD5)
- 보안 해시 알고리즘(SHA)^[7](예: SHA-256): 메시지에 대한 256비트 해시 값을 생성합니다.

실제 모든 암호화 알고리즘과 마찬가지로 위에서 언급한 알고리즘은 본 요약 기사에서 다루지 않는 다양한 중요 요구 사항에 따라 고안되었습니다. 하지만 넓은 관점에서 보면 키 기반 알고리즘에서는 키 없이 암호를 해독하는 것이 거의 불가능하거나 최소한 경제적으로 실행 불가능한 암호 텍스트를 생성해야 합니다. 해시 알고리즘에서는 해시를 빠르게 생성해야 합니다. 여기서 동일한 입력 메시지에 대해서는 동일한 해시를 생성하되 입력 메시지를 약간만 변경해도 완전히 다른 해시를 생성하며, 다른 두 메시지에 대해 동일한 해시 값을 생성하는 일은 없으며 특정 해시 값을 감안하여 원본 메시지를 생성할 수도 없습니다.

이러한 암호화 알고리즘은 세부적으로 많은 차이가 있지만 모든 알고리즘은 일련의 하위 수준 조작 및 변형과 전체 목적을 달성하기 위해 고안된 기타 수학 연산을 사용합니다. 예를 들어 AES 암호화에서는 사용자의 원래 보안 키에서 파생된 고유한 "라운드 키"를 통합하는 "라운드"를 사용하여 일반 텍스트를 암호 텍스트로 변환합니다(목록 1).

복사
Cipher(byte in[4*Nb], byte out[4*Nb], word w[Nb*(Nr+1)]) 
begin 
   byte  state[4,Nb]
 
  state = in
 
   AddRoundKey(state, w[0, Nb-1])
 
    for round = 1 step 1 to Nr–1
        SubBytes(state)
        ShiftRows(state)
        MixColumns(state)
        AddRoundKey(state, w[round*Nb, (round+1)*Nb-1]) 
    end for 
 
    SubBytes(state)
    ShiftRows(state)
    AddRoundKey(state, w[Nr*Nb, (Nr+1)*Nb-1]) 
 
    out = state
end

목록 1: 이 유사 코드는 보낸 사람의 개인 키에서 파생된 값 세트(w)를 사용하여 일반 텍스트(in)를 암호 텍스트(out)로 변환함으로써 메시지 암호화에 포함되는 작업 시퀀스를 설명합니다. (코드 출처: NIST)

라운드 내에서 SubBytes() 변환은 대체표(S 상자)를 사용하여 각 바이트를 대체합니다. 대체표는 그 자체로 일련의 변환 결과입니다(그림 1).

대체표(S 상자)를 사용하여 각 바이트를 대체하는 SubBytes() 단계의 구성도 그림 1: AES 암호화의 SubBytes() 단계에서는 대체표(S 상자)를 사용하여 각 바이트를 대체합니다. (이미지 출처: NIST)

시퀀스의 다음 단계에서 ShiftRows() 변환은 마지막 세 행의 바이트를 각각 서로 다른 바이트 수만큼 이동합니다(그림 2).

AES 암호화 실행 시퀀서의 ShiftRows() 단계 구성도 그림 2: AES 암호화 실행 시퀀스의 ShiftRows() 단계에서는 오프셋을 늘려서 행을 이동합니다. (이미지 출처: NIST)

시퀀스의 마지막 단계에서 MixColumns()는 열의 각 바이트를 다항식의 결과로 대체하는 변환을 각 열에 적용하고, AddRoundKey()는 해당 용도로 생성된 라운드 키를 사용하여 각 열에서 비트 XOR 연산을 수행하여 결과를 변환합니다.

총 라운드 수는 키 크기(비트 수)에 따라 다릅니다. 128비트 키를 사용하는 AES-128은 10 라운드가 필요하고, AES-192(192비트) 및 AES-256(256비트)은 각각 12 라운드 및 14 라운드가 필요합니다. 암호 해독에서는 공정 단계와 개별 변환을 반전시키는 동일한 패턴을 따릅니다.

키 교환에 사용되는 ECDH와 디지털 서명에 사용되는 ECDSA와 같은 최신 암호화에서는 수식에 의해 폭넓게 정의되는 타원 곡선 구조와 같은 더 복잡한 수학을 사용합니다.

방정식 1

곡선 파라미터 a 및 b를 주의해서 선택하고 추가 제약을 사용하여 곡선은 유용한 암호화 속성을 나타냅니다(본 기사에서 다루지 않음). 개념적으로 간단하지만 특정 파라미터는 중요합니다. 즉, 곡선 파라미터를 잘못 선택하면 정교한 공격에 여전히 취약한 곡선이 생성될 수 있습니다. 이러한 가능성을 제거하기 위해 NIST는 P-192, P-224, P-256 및 기타 더 높은 강도의 강력하게 암호화된 표준 곡선 세트를 제공합니다. 곡선 이름은 곡선의 기본 프라임 필드에 있는 요소의 소수 p의 비트 길이에 해당합니다.

개발자는 이러한 속성을 ECDSA와 함께 사용하여 합의된 곡선으로 일부 메시지에 서명하고 수신자에게 공용 키와 서명(r 및 s 레이블의 숫자 쌍)을 제공합니다. 실제 서명 공정은 다음 단계를 포함합니다.

곡선의 일부 지점, 즉 기준점 G(x,y)부터, 알고리즘에서는 기준점에 개발자의 개인 키(d) 모듈식 p를 곱하여 공용 키 Q(x,y)를 생성합니다.

방정식 2

다른 좌표점(x₁,y₁)은 [1 ... n-1] 범위 내에서 난수 k를 사용하여 생성됩니다.

방정식 3

H(m)(메시지 m의 SHA 해시)이 생성됩니다.
난수 k의 모듈식 역원 k^-1을 사용하여 디지털 서명의 최종 r 및 s 요소를 다음과 같이 생성합니다.

방정식 4

방정식 5

최종 결과는 메시지를 인증하고, 무결성을 확인하고, 부인 방지를 보장하는 교환입니다.

암호화 알고리즘을 구현하는 방법

이러한 알고리즘을 피상적으로 보여주는 실례에 따르면 암호화 알고리즘에서는 결과를 절충하려고 시도하도록 설계된 수학 연산 시퀀스를 사용하여 높은 계산 비용으로 인해 범죄자가 유용한 속도로 완료하는 것이 불가능하거나 실용적이지 않도록 만듭니다. 또한 각 알고리즘을 간략히 검토하면 리소스 제약이 있는 IoT 장치에서는 장치의 주요 기능 요구 사항을 잠재적으로 절충하지 않고 알고리즘의 소프트웨어 구현을 실행할 가능성이 낮다는 것을 알 수 있습니다. 마지막으로 여기에 표시된 단계에 더하여 알고리즘을 자세히 살펴보면 사소한 코딩 오류나 표준을 약간만 잘못 해석하더라도 보안 취약성이 드러나거나 암호화 공정이 완전히 실패할 수 있습니다.

알고리즘 구현 오류는 아무리 큰 개발 조직이나 해당 알고리즘을 엄격하게 따르는 응용 분야에서도 발생할 수 있습니다. 예를 들어 ECDSA의 회사 기반 구현에서 방정식 3에 표시된 계산 유형을 위한 난수 값 대신 상수 값 k를 사용하여 게임 콘솔에서 잘 알려진 취약성이 발생했습니다. 따라서 해커는 보안 키 d를 도출할 수 있습니다. k를 생성하는 데 결함 있는 난수 생성기를 사용하여 주요 비트코인 손실과 유사한 악용 사례로 이어졌습니다.

프로세서 및 전용 보안 IC에 내장된 하드웨어 기반 암호화 기능을 사용하면 개발자가 암호화 알고리즘 실행의 복잡한 세부 정보를 무시하고 해당 기능을 사용하여 응용 제품을 보호하는 데 주력할 수 있습니다. 이러한 장치는 장치 내에서 데이터 흐름과 작업을 통합하고, 외부 버스에서 권한 있는 정보의 흔적을 모니터링하는 일반적인 형태의 공격을 제거하여 보안을 한층 강화합니다. 특정 알고리즘에 대한 신뢰할 수 있는 구현을 제공하는 외에도 하드웨어 기반 솔루션을 사용하면 개발자가 응답 대기 시간, 전체 성능과 같은 기본적인 요구 사항에 영향을 주지 않으면서 설계 시 보안 기능을 내장시킬 수 있습니다.

이러한 장치에 내장된 암호화 가속기는 주요 프로세서의 암호화 실행 부담을 완화하여 설계의 기본 기능을 처리할 수 있는 여력을 제공합니다. 실제로 하드웨어 기반 암호화 지원은 점차 프로세서의 일반적인 특징으로 자리 잡았습니다. 동시에 위에서 설명한 알고리즘에서 지원하는 전체 보안 조치가 모든 응용 제품에 필요한 것은 아닙니다. 개발자는 광범위한 가속화된 암호화 알고리즘과 다음과 같은 프로세서의 알고리즘 조합을 찾을 수 있습니다.

Maxim Integrated의 MAX32631 32비트 마이크로 컨트롤러는 AES 및 DSA 암호화를 지원합니다.
Maxim Integrated의 MAX32520 32비트 MCU는 AES, SHA 및 ECDSA 알고리즘을 지원합니다.
Microchip Technology의 PIC 24F XLP 16비트 마이크로 컨트롤러 제품군(예: PIC24FJ256GA406)은 AES 및 3DES 암호화를 지원합니다.
Microchip Technology의 32비트 PIC 32MZ MCU 및 32비트 SAM9X60 MPU 제품군(예: PIC32MZ2048EFM144 및 SAM9X60T 제품)은 AES 및 3DES 암호화와 SHA 및 HMAC 해시 함수를 모두 지원합니다.
Texas Instruments의 SimpleLink MCU 제품군(예: CC1312R 및 CC2652R 무선 MCU)은 AES, ECDH 및 ECDSA 암호화와 SHA 해시 함수를 모두 지원합니다.

Maxim Integrated DS28E38 및 Microchip Technology ATECC608A와 같은 다른 보안 장치는 인증 프로토콜을 가속화하는 데 필요한 암호화 가속기와 관련 기능을 통합합니다. 폭넓은 암호화 기능과 함께 이러한 장치는 앞서 설명한 ECDSA 연산을 지원합니다. IoT 장치 또는 스마트 주변 장치에서 호스트 프로세서는 이러한 인증 IC를 사용하여 다른 장치에 보낼 ECDSA P-256 디지털 서명을 빠르게 생성하거나 다른 장치의 ECDSA P-256 서명을 인증할 수 있습니다.

보안 지원 프로세서와 특수 장치는 일반적으로 고품질 난수 생성기와 같은 추가 보안 기능을 제공하는 광범위한 하드웨어 기반 보안 프레임워크에 따라 구축됩니다. 이 정도 수준의 기능을 제공하는 대부분의 장치는 반도체 설계에 고유한 임의의 잡음 출처를 활용하여 실제 난수 생성기(TRNG)에 필요한 엔트로피를 최대화합니다. 앞서 언급한 비트코인 사례에서 알 수 있듯이 이러한 종류의 TRNG는 암호화 알고리즘을 적절히 작동하는 데 필수적인 요소입니다.

개인 키 보안 스토리지와 기타 보안 데이터 지원을 통합하는 것은 보안 설계의 가장 중요한 기능 중 하나입니다. 이 프로세서와 유사 프로세서에서 사용 가능한 다른 아키텍처 기능은 훨씬 깊이 있는 보안 지원을 제공합니다.

모든 기능을 지원하기 위해 암호화 가속기와 관련 기능을 통합한 프로세서를 사용하면 간단한 응용 프로그래밍 인터페이스(API) 라이브러리를 사용하여 보안 설계 배포를 간소화할 수 있습니다. 직관적인 API 함수 호출을 활용하면 개발자가 API를 사용하여 기본 하드웨어 기능에 액세스함으로써 보안 구현을 추상화할 수 있습니다. 예를 들어 개발자는 Maxim Integrated의 MAX32520 MCU용 MAX32520-KIT 평가 키트를 Maxim Integrated Micros 소프트웨어 개발 키트(SDK)와 함께 사용하여 보안 IoT 장치를 빠르게 빌드할 수 있습니다. 연결된 드라이버 및 미들웨어와 함께 Maxim Integrated Micros SDK에는 AES 암호화를 사용하여 (AES128_ECB_enc())를 암호화하고 (AES128_ECB_dec ()) 메시지를 암호 해독하는 데 필요한 기본 설계 패턴을 보여주는 샘플 함수가 포함되어 있습니다(목록 2).

복사
int AES128_ECB_enc(int asynchronous)
{
    printf( asynchronous ? "Test Cipher Async\n" : "Test Cipher Sync\n");
 
    char *_key = "797f8b3d176dac5b7e34a2d539c4ef36";
    char key[MXC_AES_KEY_128_LEN];
    ascii_to_byte(_key, key, MXC_AES_KEY_128_LEN);
 
    const char *iv_src = "";
    char iv_dst[16];
    ascii_to_byte(iv_src, iv_dst, 16);
 
    char *_pt= "00000000000000000000000000000000";
    char pt[MXC_AES_DATA_LEN];
    ascii_to_byte(_pt, pt, MXC_AES_DATA_LEN);
 
    mxc_ctb_cipher_req_t cipher_req = {
        (uint8_t*)pt,
        MXC_AES_DATA_LEN,
        (uint8_t*)iv_src,
        (uint8_t*)result,
        &Test_Callback };
 
    // Reset crypto block
    MXC_CTB_Init(MXC_CTB_FEATURE_CIPHER | MXC_CTB_FEATURE_DMA);
    MXC_CTB_IntEnable(asynchronous);
 
 
    MXC_CTB_Cipher_SetMode(MXC_CTB_MODE_ECB);
    MXC_CTB_Cipher_SetCipher(MXC_CTB_CIPHER_AES128);
    MXC_CTB_Cipher_SetKeySource(MXC_CTB_CIPHER_KEY_SOFTWARE);
 
    // Load key into cipher key register
    MXC_CTB_Cipher_SetKey((uint8_t *)key, MXC_AES_KEY_128_LEN);
 
    if (asynchronous){
        wait = 1;
        MXC_CTB_Cipher_EncryptAsync(&cipher_req);
        while( wait );
    } else {
        MXC_CTB_Cipher_Encrypt(&cipher_req);
    }
    const char *_expected = "322FD6E503395CDB89A77AC53D2B954F";
    char expected[MXC_AES_DATA_LEN];
    ascii_to_byte(_expected, expected, MXC_AES_DATA_LEN);
 
    return AES_check(result, expected, MXC_AES_DATA_LEN);
 
}
 
int AES128_ECB_dec(int asynchronous)
{
    printf( asynchronous ? "Test Cipher Async\n" : "Test Cipher Sync\n");
 
    char *_key = "797f8b3d176dac5b7e34a2d539c4ef36";
    char key[MXC_AES_KEY_128_LEN];
    ascii_to_byte(_key, key, MXC_AES_KEY_128_LEN);
 
    const char *iv_src = "";
    char iv_dst[16];
    ascii_to_byte(iv_src, iv_dst, 16);
 
    char *_pt= "322FD6E503395CDB89A77AC53D2B954F";
    char pt[MXC_AES_DATA_LEN];
    ascii_to_byte(_pt, pt, MXC_AES_DATA_LEN);
 
    mxc_ctb_cipher_req_t cipher_req = {
        (uint8_t*)pt,
        MXC_AES_DATA_LEN,
        (uint8_t*)iv_src,
        (uint8_t*)result,
        &Test_Callback };
 
    // Reset crypto block
    MXC_CTB_Init(MXC_CTB_FEATURE_CIPHER | MXC_CTB_FEATURE_DMA);
    MXC_CTB_IntEnable(asynchronous);
 
 
    MXC_CTB_Cipher_SetMode(MXC_CTB_MODE_ECB);
    MXC_CTB_Cipher_SetCipher(MXC_CTB_CIPHER_AES128);
    MXC_CTB_Cipher_SetKeySource(MXC_CTB_CIPHER_KEY_SOFTWARE);
 
    // Load key into cipher key register
    MXC_CTB_Cipher_SetKey((uint8_t *)key, MXC_AES_KEY_128_LEN);
 
    if (asynchronous){
        wait = 1;
        MXC_CTB_Cipher_DecryptAsync(&cipher_req);
        while( wait );
    } else {
        MXC_CTB_Cipher_Decrypt(&cipher_req);
    }
    const char *_expected = "00000000000000000000000000000000";
    char expected[MXC_AES_DATA_LEN];
    ascii_to_byte(_expected, expected, MXC_AES_DATA_LEN);
 
    return AES_check(result, expected, MXC_AES_DATA_LEN);
}

목록 2: 개발자는 Maxim Integrated Micros SDK 배포 패키지의 샘플 코드를 검사하여 MAX32520 MCU의 통합 암호화 함수를 통해 AES 암호화(AES128_ECB_enc()) 및 암호 해독(AES128_ECB_dec ())을 수행하는 데 필요한 기본 설계 패턴을 파악할 수 있습니다. (코드 출처: Maxim Integrated)

인증 프로토콜

응용 분야에서 사용되는 상위 수준 프로토콜에 대한 보안 기반을 제공하려면 강력한 암호화 알고리즘을 구현하는 것이 중요합니다. TLS(Transport Layer Security)와 같은 상위 수준 프로토콜은 일반적으로 암호 그룹이라는 정의된 암호화 알고리즘을 사용하여 연산을 수행합니다. TLS에서 합의된 암호 그룹에서 도출된 알고리즘을 사용하면 IoT 장치 클라이언트와 호스트 서버 간의 통신 세션에서 인증과 기밀성을 보장할 수 있습니다. TLS 1.2[8]는 특정 트랜잭션 시퀀스를 통해 데이터 교환을 진행하기 이전에 파라미터를 협상하고, 인증을 수행하고, 세션 키를 교환합니다(그림 3).

TLS 1.2 세션 생성 프로토콜의 구성도 그림 3: TLS 1.2 세션 생성 프로토콜에서는 합의된 암호 그룹의 다양한 알고리즘을 사용하여 인증, 키 교환 및 지속적 데이터 교환을 수행합니다. (이미지 출처: Texas Instruments)

각 참가자에 해당하는 공용 키를 포함하는 보안 인증서를 확인하여 서버와 클라이언트(선택적)의 ID를 설정함으로써 인증을 보장합니다. 여기서 각 참가자는 개인 키로 암호화된 메시지를 전송합니다. 수신된 공용 키는 연결된 개인 키로 암호화된 메시지만 암호 해독할 수 있으므로 각 참가자는 인증서 제공업체가 해당 인증서를 실제로 소유한 것을 확인할 수 있습니다.

다음 TLS 단계에서 참가자는 일련의 트랜잭션을 실행하여 공유 세션 키를 생성합니다. 그런 다음 해당 고유 세션 키를 사용하여 실제 메시지 트래픽을 암호 해독함으로써 해당 세션에 대한 메시지 교환의 기밀성을 보장합니다.

개발자는 다양한 프로토콜 옵션을 사용하여 이 일반 TLS 세션 생성 공정을 구체화할 수 있습니다. 이 과정에서 전체 보안이 훼손되는 경우도 있습니다. 또한 파라미터 교환 공정 중에 개발자는 프로토콜의 각 단계에 적합한 TLS 1.2 지원 알고리즘 조합을 선택하여 다음과 같은 다른 암호 그룹을 사용할 수 있습니다.

키 설정: RSA, DH, ECDH
인증: RSA, DSA, ECDSA
암호화: 3DES, AES
메시지 인증: SHA

최신 버전의 TLS, TLS 1.3[9]는 먼저 키 교환을 수행하여 세션 생성 공정을 효율적으로 보호함으로써 보안을 한층 강화합니다. 기본적으로 TLS 1.3에서는 HMAC 기반 추출 및 확장 키 유도 함수(HKDF), 연결된 데이터로 인증된 암호화(AEAD) 알고리즘과 같은 보다 강력한 알고리즘을 지지하여 TLS 1.2 암호 그룹을 대부분 폐기했습니다. AEAD 알고리즘은 메시지 인증, 무결성, 기밀성 보장에 대한 광범위한 요구 사항을 충족합니다. 이러한 알고리즘은 직렬(그림 4, 왼쪽), 병렬(그림 4, 오른쪽) 또는 둘의 조합으로 생성 가능한 MAC과 암호화된 메시지를 결합합니다.

인증 및 기밀성을 제공하는 AEAD의 구성도 그림 4: AEAD는 각각 직렬 또는 병렬로 MAC을 계산하는 ETM(encrypt-then-MAC, 왼쪽) 및 EAM(encrypt-and-MAC, 오른쪽) 방법을 다른 기술과 함께 사용하여 암호 텍스트에 MAC을 포함하여 인증 및 기밀성을 제공합니다. (이미지 출처: Wikipedia)

보안 강화

이 진화된 암호화 알고리즘과 연결된 프로토콜을 통해 보안을 강화하려는 암호화 전문가와 보안을 무력화하려는 보안 전문가 간의 지속적인 경쟁을 추적합니다. 예를 들어 보안을 강화하기 위해 전문가들이 DSA(이전 암호화의 변형)의 ECC 변형으로 ECDSA를 생성했습니다. 그 결과 ECDSA는 훨씬 작은 키 크기로 DSA와 동일한 보안 강도를 실현할 수 있습니다.

암호화에서 알고리즘 보안 강도는 x비트의 측면에서 정의되며 공격을 통해 이 알고리즘을 기반으로 하는 개인 키를 추출하려면 약 2^x의 작업이 필요할 것으로 예측됩니다. 이러한 측면에서 정의된 각 알고리즘은 유사한 수준의 보안을 실현하기 위해 완전히 다른 키 길이가 필요할 수 있습니다(표 1).

다양한 암호화 알고리즘 표 표 1: 암호화 알고리즘마다 유사한 수준의 보안 강도를 실현하기 위한 공용 키(L) 또는 개인 키(N, k, f)를 생성하는 데 완전히 다른 키 크기가 필요할 수 있습니다. (이미지 출처: NIST)

NIST의 이 표에서 FFC 알고리즘 파라미터 L 및 N은 각각 공용 키 및 개인 키의 크기에 해당합니다. IFC 및 ECC 알고리즘의 경우 k 및 f는 각각 키 크기에 해당합니다. NIST에 따르면 보안 강도가 £80(표의 주황색 배경)인 보안은 정보 보호를 위해 더 이상 승인되지 않고, 다른 보안(노란색 배경)은 효율성 문제로 인해 NIST 표준에 아직 포함되지 않았습니다.

암호화 및 권장 암호 그룹의 진화를 촉진하기 위해 더 높은 보안 강도로 지속적으로 이동하고 있습니다. 예를 들어 U.S. NSA(National Security Agency) CNSA(Commercial National Security Algorithm) 제품군에서는 일급 비밀로 분류된 정보를 보호하는 데 필요한 더 강력한 파라미터 사용하기 위한 권장 사항으로 이전 NSA 제품군 B를 대체했습니다(표 2).

최소 수준의 보안 강화에 대한 권장 사항과 암호화 알고리즘을 보여주는 표 표 2: NSA 권장 CNSA 제품군에는 매우 민감한 정보를 보호하는 데 필요한 최소 수준의 보안 강도에 대한 권장 사항과 암호화 알고리즘이 포함되어 있습니다. (이미지 출처: Digi-Key, NSA 제공 데이터)

미래에는 양자 컴퓨팅 기능의 출현으로 일반적인 보안 기능, 특히 암호화 알고리즘이 급격하게 중단될 것입니다.

결론

IoT 장치와 기타 연결된 설계에서는 점점 더 많은 위협에 직면하여 광범위한 암호화 알고리즘을 기반으로 하는 더욱 강력한 보안 방법이 필요합니다. 보안 균열을 비현실적인 명제로 만들기 위해 고안된 이러한 알고리즘에서는 일련의 변환과 수학 연산을 사용하여 일반 텍스트를 암호 텍스트로 암호화하고, 암호 텍스트를 일반 텍스트로 암호 해독합니다. 위에서 살펴본 바와 같이, 개발자는 이러한 알고리즘의 하드웨어 기반 구현을 사용하여 기능 및 성능에 대한 기본 요구 사항을 훼손하지 않으면서 강력한 보안을 보다 쉽게 설계에 구축할 수 있습니다.