IoTセキュリティを支えるTLS 1 · サーバーは暗号化された EncryptedExtensions を送信暗号パラメータの決定に必要でないClientHello のTLS拡張

IoT次世代のIoTセキュリティを支えるTLS 1.3

1

1. 本セッションの内容

2. wolfSSLの軌跡

3. TLS 1.3の変更点

4. TLS 1.3ハンドシェーク

5. TLS 1.3ハンドシェーク派生形

6. TLS 1.3 とwolfSSL

7. Q&A

アジェンダ

Chris ConlonEngineering Manager, wolfSSLEmail: [email protected]

古城隆wolfSSL Japan合同会社　技術統括Email: [email protected]

mailto:[email protected]


wolfSSLの軌跡

wolfSSLの製品

● デュアルライセンス GPLv2 と商用版

● ソースコードは次から入手可能:

○ wolfSSL ウェブサイト

www.wolfssl.jp/download/

○ GitHubwww.github.com/wolfssl

● wolfSSLエンジニアによるベンダーサポート

● インテグレーションと新機能のコンサルティングサービス

wolfSSLの紹介 - オープンソース

https://www.wolfssl.jp/download/

http://www.github.com/wolfssl

● 1995年にTLSが発行されてから数々の脆弱性が発見されている

● TLS 1.3 がこれらの問題を解決し、新たな問題を予防

○ BEAST○ CRIME○ Lucky 13○ Heartbleed○ POODLE○ BERserk○ FREAK

○ Bar Mitzvah Attack○ Logjam○ Pandora’s Box Attack○ SLOTH○ DROWN○ SWEET32○ ROBOT○ ...

以前のバージョンのTLSには多くの脆弱性の問題

● 整理と削除 - 使われていない、もしくは安全でない機能を削除

● プライバシー向上 - ハンドシェークをより多く暗号化

● レイテンシー向上 - 新しいセッション1-RTT、セッション再開には0-RTT

● 継続性 - ユースケースレベルの互換性保持

● セキュリティ - 専門家による分析、設計

TLS 1.3のゴール

● 最終版までに5年の年月● 28 回のドラフト仕様リリース

TLS 1.3の歴史

DRAFT RFC8446August 2018

● 暗号アルゴリズムの変更

● 安全でない機能の整理、削除

● ハンドシェークメッセージの多くが変更

● ハンドシェークメッセージの暗号化

● 0-RTT モード

● キーデリベーションアルゴリズムが改善

● セッション再開の変更

𝚫TLS 1.3の変更点

アルゴリズムの変更

● 共通鍵暗号のリストは”レガシー”アルゴリズムとして削除

● TLS1.3 アルゴリズムは全て認証付き暗号を使用（Authenticated Encryption with Associated Data , AEAD)

● 暗号スイートは認証と鍵交換メカニズムを暗号アルゴリズムから分離

TLS 1.2とTLS 1.3の主な違い

TLS 1.2 Cipher Suite Format

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

TLS 1.3 Cipher Suite Format

TLS_AES_128_GCM_SHA256

認証と鍵交換Note: 含まれなくなった

TLS1.3ではECCが正式採用

● 基本スペックに含まれる

● 新しい署名アルゴリズム（例：ed25519, ed448)

● ポイントフォーマットネゴシエーションは、1つの曲線につき一つのポイントフォーマッ

トのために削除された

静的 RSA とDH暗号スイートは削除

TLS 1.2とTLS 1.3の主な違い(続き)

その他の暗号化改良

● 削除

○ データ圧縮

○ カスタム DHE グループ

○ DSA

● RSAパディングはPSSを使用するように変更

○ PSS = “Probabilistic Signature Scheme”


ハンドシェークメッセージをより暗号化

● ServerHello後のハンドシェークは全て暗号化

TLS 1.2 TLS 1.3


● 0-RTT = Zero Round Trip Time

● パフォーマンス改善

● アプリケーションデータの送信にハンドシェーク1往復の節約

● ClientHelloで最初のアプリケーションデータ(early data)を送信

● 以前のセッションの鍵情報を再利用

ClientHello+ Application DataClient Server


キーデリベーション機能の見直し

● より簡潔な分析を可能にする

● HMAC-based Extract-and-Expand Key Derivation Function (HKDF) を採用


バージョンネゴシエーションの削除

● TLS 1.2 にはバージョンネゴシエーションが存在

● TLS 1.3 ではバージョンリストをTLS拡張に明示

VersionNegotiation

Version Listin Extension


セッション再開

● Single new PSK exchange

○ サーバー側の状態がなくてもいいようセッション再開を見直し

○ TLS1.2までのPSKをベースにした暗号スイートを見直し

● ミドルボックス互換のために“legacy_session_id” をClientHelloに追加


● 3つの鍵交換をサポート：

(EC)DHE

楕円曲線ディフィー・

ヘルマン鍵共有

PSK事前共有鍵のみ

(EC)DHE + PSK事前共有鍵 -楕円曲線

ディフィー・ヘルマン鍵共有


● 3つのフェーズ:

a. 鍵交換

■ 鍵情報の共有の確立と暗号化パラメータの選択。その後は全て暗号化される。

b. サーバーパラメータ

■ その他のハンドシェイク・パラメータを確立（例：クライアント認証、 ALPN等）

c. 認証

■ サーバー認証（オプションとしてクライアント認証）、鍵認証とハンドシェイク一貫性

TLS 1.3 - フル・ハンドシェイク

19

Key ExchangePhase

Server ParametersPhase

AuthenticationPhase


ClientHellokey_share*signature_algorithms*psk_key_exchange_modes*pre_shared_key*

ServerHellokey_share*pre_shared_key*

EncryptedExtensions

CertificateRequest*

Certificate*

CertificateVerify*

Finished

Application Data*

Certificate*

CertificateVerify*

Finished

Application Data Application Data

Client Server




EncryptedExtensions

CertificateRequest*

Certificate*

CertificateVerify*

Finished

Application Data*

Certificate*

CertificateVerify*

Finished


Client Server● クライアントは下記を含む ClientHello を送信：

○ Random nonce (ClientHello.random)

○ プロトコルバージョン (TLS 1.3)

○ 対称暗号スイートのリスト /HKDF のハッシュ・ペア

○ ディフィー・ヘルマン鍵共有 (“key_share” の TLS拡張 ) AND/OR

○ 事前共有鍵のラベル (“pre_shared_key” の TLS拡張 )

○ オプションとして、その他の TLS拡張



EncryptedExtensions

CertificateRequest*

Certificate*

CertificateVerify*

Finished

Application Data*

Certificate*

CertificateVerify*

Finished


Client Server● サーバーはSeverHelloに応答し、ネゴシエーション済み接続パラメータを提

示

○ EC(DHE)が使用されている場合、サーバーの一時的なDH共有（ク

ライアントの共有と同じグループ内）が「key_share」TLS拡張に含ま

れる

○ PSKが使用される場合、”pre_shared_key” TLS拡張にクライアント

側で選択された事前共有鍵（PSK)を示す

○ EC(DHE) と PSK が共に使用される場合、両方の TLS 拡張が存在

する




CertificateRequest*

Certificate*

CertificateVerify*

Finished

Application Data*

Certificate*

CertificateVerify*

Finished


Client Server

● サーバーは暗号化された

EncryptedExtensions を送信

● 暗号パラメータの決定に必要でないClientHello のTLS拡張に応答


EncryptedExtensionsExamples:

server_name RFC 6066max_fragment_length RFC 6066supported_groups RFC 7919use_srtp RFC 5764application_layer_protocol_negotiation RFC 7301



Certificate*

CertificateVerify*

Finished

Application Data*

Certificate*

CertificateVerify*

Finished


Client Server

● Server sends CertificateRequest

○ If client authentication is desired (otherwise omitted)


EncryptedExtensions

CertificateRequest*



CertificateVerify*

Finished

Application Data*

CertificateVerify*

Finished


Client Server

● Certificate

○ Can be sent by both client and server○ Certificate of endpoint


EncryptedExtensions

CertificateRequest*

Certificate*

Certificate*



Finished

Application Data*

Finished


Client Server


EncryptedExtensions

CertificateRequest*

Certificate*

Certificate*

CertificateVerify*

CertificateVerify*

● CertificateVerify

○ Signature over entire handshake, using private key corresponding to public key in Certificate message



Application Data*


Client Server


EncryptedExtensions

CertificateRequest*

Certificate*

Certificate*

CertificateVerify*

CertificateVerify*

Finished

Finished

● Finished message

○ MAC over entire handshake

○ Provides key confirmation, binds endpoint identity to exchanged keys

○ Authenticates handshake in PSK mode

TLS 1.3最適化されたハンドシェイクの派生形

1. 再開と事前共有鍵（PSK）

2. 0-RTT データ (0-RTT)

28

再開と事前共有鍵（PSK）

ハンドシェイク派生形 #1

29

● セッション再開と事前共有鍵 (PSK)

○ “セッション再開”

○ PSKは以前のコネクションで確立し、再開で使用

○ ハンドシェークが終わると、サーバーはハンドシェークから派生した鍵に対応し

たPSKアイデンティティをNewSessionTicketとして初めのクライアントに送る

○ クライアントは以後のハンドシェークにPSKを用いたネゴシエーションをするた

めにPSKアイデンティティを使う

TLS 1.3 - Optimized Handshake Variants

● 再開と事前共有鍵（PSK）○ PSKは、(EC)DHE鍵交換と共に使用可能

■ 共有鍵との組み合わせで前方秘匿性を提供

○ PSKは単体でも使用可能だが

■ 前方秘匿性は低下する

TLS 1.3 - 最適化されたハンドシェイクの派生形

TLS 1.3 - PSK 最初のハンドシェイク

ClientHellokey_share*

ServerHellokey_share*

EncryptedExtensions

CertificateRequest*

Certificate*

CertificateVerify*

Finished

Application Data*

Certificate*

CertificateVerify*

Finished


Client Server

NewSessionTicket

TLS 1.3 - PSK 再開ハンドシェイク

ClientHellokey_share*psk_key_exchange_modespre_shared_key ServerHello

pre_shared_keykey_share*

EncryptedExtensions

Finished

Application Data*

Finished


Client Server

● Resuming with PSK, so no Certificate or CertificateVerify

● Client “key_share” allows server to fall back to full handshake if desired

● Server can send “key_share” back to do EC(DHE)

0-RTT データ

ハンドシェイク派生形 #2

34

● 0-RTT データ

○ クライアント/サーバーがPSKを共有する時、クライアントは最初のメッセージで

データを送信可能 - ”early data”と呼ばれる

○ クライアントはPSKをサーバー認証と”early data”の暗号化の為に使用する

○ PSKは外部から取得か、または以前のハンドシェイクを通して取得可能

■ PSKは外部から取得した場合、下記項目が必要

● PSKと共に使用される暗号スイート

● アプリケーションレイヤ・プロトコル・ネゴシエーション（ALPN）

● サーバー名表示 (SNI)


● Zero-RTT Data

○ Early dataは最初のフライト内で、1-RTTハンドシェイクに続く

○ ハンドシェイクの残り部分は、PSK再開を伴う1-RTTと同一メッセージを使用す

る

○ RFC 警告:

■ 0-RTTのセキュリティ属性は、他の TLSデータに比べ安全性が弱い

■ データは前方秘匿性がない (共有鍵との組み合わせで前方秘匿性を提供 )

■ TLS を使用するプロトコルが、その使用を定義するプロファイルなしで 0-RTT データを使用

してはいけない


TLS 1.3 - 0-RTT ハンドシェイク

ClientHelloearly_datakey_share*psk_key_exchange_modespre_shared_key

ServerHellopre_shared_keykey_share*

EncryptedExtensionsearly_data*

Finished

Application Data*

Finished


Client Server

Application Data

EndOfEarlyData

では、使い手にとってTLS1.3はどの様な

利点があるのでしょう？

38

● パフォーマンスの改善!

○ より高速なハンドシェーク確立

■ TLS 1.2 - 2 往復

■ TLS 1.3 - 1 往復

○ 通信遅延は接続確立時間への影響が小さい

○ 選択肢として, 先頭に 0-RTTメッセージ!

TLS 1.3 - 利点

39

TLS 1.3 - 利点

40

● より安全に!

○ 古く、安全性に疑問のある下記のアルゴリズムが削除

■ 静的RSAによる鍵送信 - 前方秘匿性が欠如

■ RC4 ストリーム暗号 - 安全でない

■ CBCモード暗号 -BEAST, Lucky13攻撃

■ SHA-1 ハッシュ機能 - 削除, SHA-2 推奨

■ 静的なディフィー・ヘルマン - CVE-2016-0701

■ 輸出用暗号 -　FREAK, Logjam攻撃

TLS 1.3 - 利点

41

TLS 1.3 と wolfSSL● wolfSSLのTLS 1.3対応

● TLS 1.3をwolfSSLで使う方法

42

● TLS 1.3 サポートを有効化：

● もしくは, 以前のドラフトをサポート

$ unzip wolfssl-X.X.X.zip$ cd wolfssl-X.X.X$ ./configure --enable-tls13$ make

$ ./configure --enable-tls13-draft18$ ./configure --enable-tls13-draft22$ ./configure --enable-tls13-draft23$ ./configure --enable-tls13-draft26$ ./configure --enable-tls13-draft28

TLS 1.3でwolfSSLをコンパイルする

43

● wolfSSL サンプルクライアントとサーバプログラムは、wolfSSLとTLS1.3の機能で

簡単にテスト可能

● 例:

○ TLS 1.3 with TLS13-AES128-GCM-SHA256 暗号スイート

$ ./examples/server/server -v 4 -l TLS13-AES128-GCM-SHA256$ ./examples/client/client -v 4 -l TLS13-AES128-GCM-SHA256

例：wolfSSL with TLS 1.3

● wolfSSLサンプルクライアントは、外部のTLS 1.3 サーバーへ接続することも可能

● 例：

○ www.cloudflare.com へ TLS13-AES128-GCM-SHA256 で接続

$ ./examples/client/client -v 4 -l TLS13-AES128-GCM-SHA2 \ -h www.cloudflare.com -p 443 -g -d


http://www.cloudflare.com

http://www.cloudflare.com

● wolfSSL は、下記のすべてのTLS 1.3 暗号スイートをサポート：

TLS13-AES128-GCM-SHA256TLS13-AES256-GCM-SHA384TLS13-CHACHA20-POLY1305-SHA256TLS13-AES128-CCM-SHA256TLS13-AES128-CCM-8-SHA256TLS13-SHA256-SHA256TLS13-SHA384-SHA384


46

● TLS 1.3 を使用するための二つの新しい client/server メソッド

● WOLFSSL_CTX作成用に：

● 関数名”_ex”付きを使用するとアプリケーションで heap ポインターを得ることが出

来る

WOLFSSL_METHOD* wolfTLSv1_3_server_method(void);WOLFSSL_METHOD* wolfTLSv1_3_client_method(void);

WOLFSSL_METHOD* wolfTLSv1_3_server_method_ex(void* heap);WOLFSSL_METHOD* wolfTLSv1_3_client_method_ex(void* heap);

wolfSSL TLS 1.3 API 使用方法

47

● TLS1.3の再開ハンドシェイクが終了した後 ticket を送付しない

int wolfSSL_CTX_no_ticket_TLSv13(WOLFSSL_CTX* ctx);int wolfSSL_no_ticket_TLSv13(WOLFSSL* ssl);

ctx - 初期化済み wolfSSL コンテクスト構造ssl - 初期化済み wolfSSL セッション構造


48

● 事前共有鍵を使用している時、（EC)DHEを許可しない

int wolfSSL_CTX_no_dhe_psk(WOLFSSL_CTX* ctx);int wolfSSL_no_dhe_psk(WOLFSSL* ssl);



49

● 暗号化・復号化の鍵を更新

○ 送信者が送信暗号鍵の更新のためのKeyUpdateハンドシェイクメッセージを送信する

○ Finishedメッセージを送信した後、どちらのピアからでも送信できます

int wolfSSL_update_keys(WOLFSSL* ssl);

ssl - 初期化済み wolfSSL セッション構造


50

● TLS 1.3接続でハンドシェイク後の認証を許可する

● クライアントが "post_handshake_auth" TLS拡張を送信した場合、サーバは、ハン

ドシェイクが完了した後、いつでも、CertificateRequestメッセージを送信することで

クライアントの認証をリクエスト出来る

○ WOLFSSL_POST_HANDSHAKE_AUTH を定義　又は

○ ./configure --enable-postauth　を指定

int wolfSSL_CTX_allow_post_handshake_auth(WOLFSSL_CTX* ctx);int wolfSSL_allow_post_handshake_auth(WOLFSSL* ssl);



51

● クライアントの証明書を要求する

○ ハンドシェイク終了後、いつでも呼び出すことが出来る

○ 1つの接続で最大256の要求を送信可能

int wolfSSL_request_certificate(WOLFSSL* ssl);


wolfSSL TLS 1.3 API 使用方法(続き)

52

● クライアントからサーバーへの接続

○ プロトコル・バージョンは TLS v1.3 を期待

○ TLS1.3オプションが有効化されていれば、wolfSSL_connect（）を使用することもできる

int wolfSSL_connect_TLSv13(WOLFSSL* ssl);



53

● サーバー側でクライアントからの接続を受け付け

○ プロトコル・バージョンは TLS v1.3 を期待

○ TLS1.3オプションが有効化されていれば、wolfSSL_accept（）を使用することもできる

int wolfSSL_accept_TLSv13(WOLFSSL* ssl);



54

● サーバーが受付可能な early_data の最大長を設定

○ ゼロを指定した場合、セッション・チケットを使用して、クライアントから early data は送信しない

○ WOLFSSL_EARLY_DATA を定義するか、又は

○ ./configure --enable-earlydata　を指定

int wolfSSL_CTX_set_max_early_data(WOLFSSL_CTX* ctx, unsigned int sz);int wolfSSL_set_max_early_data(WOLFSSL* ssl, unsigned int sz);

55


● early data 付きでサーバーへTLS接続

int wolfSSL_write_early_data(WOLFSSL*, const void*, int, int*);

56


● クライアントから early data 付きでTLSアクセプト

int wolfSSL_read_early_data(WOLFSSL* ssl, void* data, int sz, int* outSz);

57


TLS 1.3に対応しました！

● wolfSSL で利用可能

● ご質問は[email protected]まで日本語でどうぞ

● オープンソースプロジェクトもサポートします

58


Documents

IoTセキュリティを支えるTLS 1 · サーバーは 暗号化された EncryptedExtensions を送信 暗号パラメータの決定に必要でないClientHello のTLS拡 張

IoTセキュリティを支えるTLS 1 · サーバーは暗号化された EncryptedExtensions を送信暗号パラメータの決定に必要でないClientHello のTLS拡張