TLSとは?

SiemensのC712とTwinCAT TF6701にMQTTを使用していたときにTLSの言葉が出てきました。TLSはTransport Layer Securityの略称でこの標準でSymmetric cryptographyとAsymmetric cryptography など一緒に応用し許可なしの第三者よりアクセスからデータを守ることができます。ちなみに今回説明するはTLSV1.2です。TLS1.2はKey交換・認証・暗号に・MACも含めています。

ClientとServerがそれらの沿って接続を成立するのです。

Communication Flow

TLS通信はServerとClient側でHandShakeから始まります。HandShakeの間ではAsymmetric ctryptographyを使用し、HandShake成功した後にServerとClient間はSymmetic ctryptographyに切り替えます。

説明する間はいくつかの言葉出てきますので、最後にそれらをまとめで説明したいと思います。では、始まりましょう。


ClientHello

ClientがServerに接続する前に、まずClient自体を初期化し、その時Serverに渡してたのはTLSのバージョン・Random Sequence bytes・Client側がサポートするCipher suites と他のパラメタになります。

Cipher Suites

TLSは本来暗号通信の一つで、その通信Flowはいくつの暗号技術やHASH関数の組み合わせで使われています。通信の部分はこちらの技術で、別の部分はまたあちらの技術で、その組み合わせのことはCipher Suites(暗号スイート)といいます、

https://tkengo.github.io/blog/2015/12/01/https-details/

ServerHello

Server側がCipher Suitesを選択し通信仕様を決めます。もしClientのCipher SuitesがServer

がSupportしないのならTLS Connectionが切断します。Server側にRandom Sequence bytesも送ります。

Certificate

Server側が自分の証明書を提示し、Clientに自分が正しいServerと接続してるかどうかを確認させます。もしClient側がServerの証明書を信頼しないのであれば、TLS Connectionが切断されます。Serverの証明書には自分のPublic Keyも入っています。

ServerExchange

ServerExchangeがClient側がPre-masterを生成するために充分なデータが含まれてない時のみ、足りないデータを送ります。

Certificate Request

次はCipher suites が含まれてるServerがClientに証明書を要求します。

ServerHelloDone

それはServerHelloに関するメッセージを終了するためにServer側が送ります。このMessage送ったあと、Client側の返事を待ちます。

Certificate

ServerHelloDoneのメッセージがClientがもらったあと、Client側が最初に送るメッセージです。ClientがCertificateをServerへ送信します。次のHandShakeはServer側と似ています。もしServer側の証明書信頼しないのであればTLS Connectionが接続されます。

Client Key Exchange

Client側Server側の公開鍵(Public Key)を使用しPre-master Secretを送信します。


Certificate Verify

そのメッセージはHandShakeの内容を署名します(Client側の証明書を検証するために)。そのHandShakeメッセージはClient Hellowからこのメッセージまで含まれています。

つまり、これは本人ですよ!の宣言です。

ChangeCipherSpec

Client側ServerにSymmetric Cryptography 方式に切り替えると伝えます。

Finished

ClientはこのTLS Connectionに暗号化済みだと示しています。受信側はこのConnectionが正しいかどうかを検証する必要があります(Hash MAC)。

ChangeCipherSpec

Server側Pre-master Secretを復号しClient側を検証します。もしOKなら、これからSymmetric Cryptography 方式に変わります。

Finished

Server側がClientにTLS Connection Readyを送信します。同じくHASH MAC使用し、もし復号が失敗なら、Connectionが切断されます。

Application data

TLS Connectionが成立したあら、User DataがSymmetric Cryptography 方式で交換します。

Symmetric cryptography?

Symmetric cryptographyは暗号化と復号化も同じのKeyを使用する手法です。まず暗号化するには1つの関数だと思ってください。入力は暗号化される前の内容でつまりPlaintextです。そしてFunctionはその出力でCipher textになります(暗号文)

その暗号文がまた別のFunctionの入力としてPlaintextに戻ります(復号)。

そこでUser1がデータをUser2を送りたいと考えています。User1がPlaintextを共有鍵を使用データを暗号化しUser2に送ります。User2は同じの共有鍵を使って暗号文を復号し平文に戻ります。

注意するのは同じの線はセキュリティのチャンネルではないと考えておきましょう。例えばWirelessなど。

ここでで第三者(例えばUserX)にこのチャンネルをずっと見ています。もちろんUserXが見えるのは暗号文だけになりますが、もしUserXが共有鍵が手に入れれば、自分で復号することができます。なのでその共有鍵をどうやって安全に・機密にUserに送るか問題です。

Asymmetric cryptography?

まず、最初に行っておくのはAsymmetric cryptographyの鍵は長いです。凄く長いです。この手法うぃ敏感なデータをしらない人に手を入れてしまうことを予防します。通信者と受信者にも自分の公開鍵(Public Key)と秘密鍵(Private Key)があります。

Public Keyを使ってデータを暗号化し、Private Keyを使ってデータを復号化するんです。

その手法はデジタル署名にも使えます。Senderにはこのひとしかない秘密鍵を使ってデータを暗号化したのです。一方、ReceiverはそのSenderのPublic Keyを使ってメッセージが本人かどうかを検証できます。

問題はありますが、その鍵は1000Bitの長さです。なので復号は時間すごく時間かかります。逆に先紹介したSymmetric cryptographyが復号化と暗号化も同じ鍵を使っていますので高速になります。ですが、セキュリティ上ではPrivate Keyは持ってるのは自分自身だけなので信頼できます。

実際そのAsymmetric cryptographyをイメージしてみましょう。

みんなさん手紙送ったことありますか?手紙が送る人がたくさんいますがね。彼らの手紙を町のPostboxに入れます。そのPostboxの場所はPublic Keyです。

そしてそのPostboxが開けるのはPostboxの所有者だけです。つまり私宛の手紙が私しかみえないのことです。このPostboxを開けるのKeyはPrivate keyです。

次は実際の流れを見てみましょう。前もいったですが、User1とUser2にも自分の公開鍵と秘密鍵があります。

User1とUser2が公開鍵を交換します。

User1がデータを送ろうとするとき、User2の公開鍵を使ってデータを暗号化しUser2へ送ります。

User2は自分のPrivate Keyを使って暗号化されたデータを復号します。なので理論上ではデータ見えるのはUser2だけになります。

Hash Based Message Authentication

まず簡単はことから始めましょう。Hashは知っていますか?

違い長さのDataはどんなデータでもいいです。画像、Word、Excelでもよいです。そのDataをHash関数の入力入れて(例えばSHA256)、そいて固定長さの出力されます。理論上では1Bitのが違っても全然違うの出力になります。

HMACがHASH関数と似ています。違い長さのDataはどんなデータでもいいです。画像、Word、Excelでもよく、HMACは二つのパラメタがあります。一つ目はHASH Function、つまり前説明したの関数です。次は大事なのはSecretです。もしUser1とUser2はHMACを使用すると同じのData入力し、同じのHASH Functionを使用し、もしSecretが違うのであれば出力も違います。

最後は流れを見てみましょう。

ここでUser1がUser2にメッセージを送ります。ここで私はUser1です、送ったMessageが修正されてないことだと証明したいです。ここでできるのは”Secret”を同意します。

そしてMessageのHMACを計算し、User2へ送ります。User2ができるのはメッセージからHMACを計算します。お互いのHMACはが同じであれば、メッセージが修正されてないことが証明できます。もちろんその”Secret”がUser1とUser2しかわかりませんので最低限そのMessageがUser1から送ってることだと信頼できます。

はーい、お疲れ様っすー。

Footer_Basic

Please Support some devices for my blog

Amazon Gift List

Find ME

Twitter:@3threes2
Email:soup01threes*gmail.com (* to @)
YoutubeChannel:https://www.youtube.com/channel/UCQ3CHGAIXZAbeOC_9mjQiWQ

シェアする

  • このエントリーをはてなブックマークに追加

フォローする