TLS

Size: px
Start display at page:

Download "TLS"

Transcription

1 SSL/TLS の基礎と最新動向 セキュリティキャンプ 年 8 月 12 日 IIJ 大津繁樹 更新版資料の置場 Github Repo:

2 自己紹介 大津繁樹 株式会社インターネットイニシアティブ プロダクト本部アプリケーション開発部サービス開発 2 課 NodeJS Technical Committee メンバー ( 主に TLS/CRYPTO/OpenSSL バインディングを担当 ) IETF httpbis WG で HTTP/2 相互接続試験等仕様策定に参画 ブログ :

3 はじめに TLS(Transport Layer Security) の仕組みについて学んでいただきます 後述するよう TLS は 様々なセキュリティの要素技術から成り立っており その一つ一つが難解で深い技術要素です 残念ながら 4 時間もの時間があってもその全てを完全に理解することは容易ではありません

4 本講義の目的 TLS の本質は 要素技術をどう組み合わせてどういう手順でセキュアな通信を確立するかというところにあります そのため 本講義の目的は TLS 技術の基礎 TLS ハンドシェイクの仕組み を理解していただくことです 聞いているだけの理解より 実際に手を動かしての体験する方を重視して進めます 課題内容は空白にしています 講義当日にお知らせします

5 本講義の内容 TLS の概要 TLS を理解する準備 TLS の話 まずは TLS_RSA_WITH_AES_128_GCM_SHA256 の時から Perfect Forward Secrecy TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 を使う 最新情報 TLS1.3 とはどういうものか? 概要説明

6 まずやってみる モジュールのインストール $npm install seccamp2015-data-reader seccamp2015-tls Simple TLS Client (simple_tls_client.js) の取得 $git clone $cd SecCamp2015-TLS $node simple_tls_client.js キーボードを打ってみよう ( 注 : エラー処理やサニタイジングが十分でないのであくまでテスト用で利用すること )

7 TLS の概要

8 インターネットの脅威 盗聴 パスワードやクレジットカード番号を盗み見

9 インターネットの脅威 改ざん 通信途中でデータを書き換え

10 インターネットの脅威 なりすまし ユーザになりすまして通信を行う

11 インターネットの脅威 否認 そんな通信してませんと否認する

12 インターネットの脅威から守るセキュリティ対策 盗聴 暗号化 改ざん 成りすまし 完全性チェック 認証 否認 署名

13 各レイヤーにおけるセキュリティ通信 S/MIME, PGP データ TLS,DTLS,SSH TCP, UDP IPsec IP WPA 無線 LAN

14 TLS の目的 RFC5246: The Transport Layer Security (TLS) Protocol Version Introduction The primary goal of the TLS protocol is to provide privacy and data integrity between two communicating applications. TLS プロトコルの最重要なゴールは 通信する 2 つのアプリケーションの間でプライバシーとデータの完全性を提供することです プライバシー アプリ アプリ 完全性

15 TLS の簡単な歴史 現在の利用推奨 SSL 1.0 未発表 1994 年 SSL 年 SSL 年 IETF TLS WG スタート 1999 年 TLS 年 TLS 年 TLS 1.2 SSL は 旧ネットスケープ社の私的プロトコル SSL3.0 と基本設計は大きく変えず 内部バージョンは TLS1.0 =SSL 年 TLS 1.3 検討スタート TLS と名前を変えて標準化 様々な拡張仕様の追加

16 TLS を理解する準備

17 TLS の要素技術 PKI X509 証明書 乱数生成 対称暗号 デジタル署名 鍵交換 公開鍵暗号 TLS メッセージ認証 暗号モード 一方向ハッシュ TLS プロトコルは これらの要素技術を組み合わせてアプリ間のセキュア通信を確立する手順を決める

18 TLS 要素技術の依存性 PKI 暗号モード X509 証明書 対称暗号 デジタル署名 メッセージ認証 鍵交換 公開鍵暗号 一方向ハッシュ 乱数生成 本来はこの一つ一つをきちんと理解してもらうのが必要

19 TLS 要素技術の依存性 PKI 暗号モード GCM X509 証明書 対称暗号 AES デジタル署名 メッセージ認証 HMAC ECDHE 鍵交換 RSA 公開鍵暗号 一方向ハッシュ SHA256 乱数生成 本日の講義で扱う技術 説明は概要だけですが 演習で実際の動作を手を動かして体験してもらいます

20 要素技術と TLS CipherSuites デジタ対称暗号 TLS _ 鍵交換 _ ル署名 _WITH_ 暗号 _ 鍵長 _ モード _ メッセージ認証 ( ハッシュ ) TLS_RSA_WITH_AES_128_GCM_SHA256 = {0x00,0x9C} 鍵交換 デジタル署名に RSA 対称暗号に 128bit 鍵長の AES 暗号モードに GCM ハッシュに SHA256 番号として 0x00,0x9C を割り当て TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256= {0xC0,0x2F}; 鍵交換に ECDHE デジタル署名に RSA 対称暗号に 128bit 鍵長の AES 暗号モードに GCM ハッシュに SHA256 番号として 0xC0,0x2F を割り当て

21 乱数生成 利用用途 : 暗号鍵 ( 対称暗号 : 秘密鍵 公開鍵暗号 : 鍵ペア ) の生成 暗号モードの初期ベクトルや Nonce(*) の生成 MAC( メッセージ認証 ) 用鍵 求められる機能無作為性 : 偏りがなく等しい数である 予測不可能性 : 次の乱数が予想できない 制限負可能性 : 同じ乱数列を再現できない (* Nonce(number used once) 一度だけ使い捨て用に使われる数字

22 乱数生成 実際の利用は 疑似乱数生成 seed が必要 OpenSSL では seed は Linux の /dev/urandom を利用 Windows では OS の API の CryptGenRandom だけでなく画面スクリーンのビットマップハッシュも利用 脆弱性 : CVE : Debian や Ubuntu の OpenSSL に予測可能な乱数を生成してしまう脆弱性 SSH 公開鍵にブルートフォース攻撃

23 対称暗号 暗号化 復号化 平文 暗号文 平文 共通鍵 共通鍵 ストリーム暗号 : データを逐次暗号化 (RC4, Chacha20) ブロック暗号 : データをブロック毎に暗号化 (DES, AES) 幾つかの暗号では既に危殆化 : DES: 2005 年 NIST FPS46-3 規格の廃止 (2030 年までは許容 ) RC4: RFC7455: Prohibiting RC4 Cipher Suites

24 対称暗号 AES 1997 年よりプロジェクト開始 2000 年選定 2001 年仕様発行 ブロックサイズ 128bit 鍵長 : 128bits, 192bits, 256bits の3 種類 Intel/AMDのCPUでハードウェア処理のサポート AES-NI

25 暗号モード ブロック暗号は同じデータを同じ鍵で暗号化すると毎回同一の暗号文になる ブロック長より長いデータを暗号化する場合に暗号モードを利用して繰り返しを避ける CBC: ( 平文 XOR ベクトル ) を暗号化 を続ける CTR: カウンターを暗号化 XOR 平文 を続ける これまでの主流 これからの主流に (GCM 後述 ) 実際に TLS で利用するには改ざん検知のための MAC( メッセージ認証 ) との組み合わせる (AEAD)

26 AEAD( 認証付き暗号 ) 暗号化しないけど改ざん防止が必要なデータ ( ヘッダ等 ) 暗号化する平文 初期ベクトル AEAD 暗号化 共通鍵 暗号文 認証タグ

27 AEAD( 認証付き暗号 ) 暗号化しないけど改ざん防止が必要なデータ ( ヘッダ等 ) 暗号文 認証タグ 初期ベクトル AEAD 復号化改ざんチェック 共通鍵 平文

28 GCM GCM (Galois Counter Mode: ガロアカウンターモード ) CTRとGHASHを組み合わせたAEAD ハードウェア処理で高速化が可能 AESと組み合わせて AES-GCMとして利用

29 一方向ハッシュ データ 一方向ハッシュ関数 ハッシュ値 ハッシュ値を比較することでデータの改ざんをチェックすることができる

30 一方向ハッシュ md5 既に現実的な攻撃手法が存在 (*1) SHA-1 SHA-2(SHA-256 など 6 種 ) 2018 年ぐらいには現実的なコストで衝突データを探せる見込み (*2) SHA-3(SHA3-256 など 6 種 ) 8/5 に NIST より正式公開 (*1) how to Break MD5 and Other Hash Functions (*2) Cryptanalysis of SHA-1

31 メッセージ認証 (HMAC) 共通鍵 データ 一方向ハッシュ関数 ハッシュ値 事前に共通鍵を共有 共通鍵とデータを組み合わせたハッシュ値を作成 データの完全性とハッシュ作成者を認証する

32 公開鍵暗号 公開鍵 秘密鍵 暗号化 復号化 解を求めるのが困難な数学的問題を利用して暗号を生成 公開鍵と秘密鍵のペアを生成 公開鍵はさらして大丈夫 公開鍵で暗号化し秘密鍵で復号化 RSA ECC( 楕円曲線暗号 ) 512bit RSA の危険性 FREAK

33 鍵交換 2 者間で安全に鍵を共有する仕組み 互いに公開鍵を交換しあい 共有鍵を生成する 通信経路上で共有鍵のやり取りがない DH (Diffie-Hellman) ECDH( 楕円曲線 DH) 512bit DH Logjam

34 デジタル署名 秘密鍵 データ + デジタル署名 公開鍵 データの完全性のチェックが可能となる データの送信元の認証が可能となる 公開鍵の信頼性の範囲で否認防止が可能となる RSA DSA,ECDSA データハッシュ値を暗号化しデジタル署名を生成 デジタル署名を復号化 データハッシュ値と比較し検証する

35 X509 証明書 (Certificate) 公開鍵と所有者 発行者やその他属性情報をデジタル署名したデータ 元々は電子ディレクトリサービス仕様 (X500) の一部 認証局 (CA) が所有者の実体を確認して証明書を発行する (PKI)

36 X509 証明書 (Certificate)

37 演習 : sudo npm install -g seccamp2015-crypto-workshopper 乱数生成 AES-GCM 公開鍵暗号 一方向ハッシュ 鍵交換 メッセージ認証 デジタル署名 X509 証明書 ( 時間がなさそうなので取りやめました )

38 TLS の話 まずは TLS_RSA_WITH_AES_128_GCM_SHA256 の時から 注 : 複雑さを避けるためクライアント認証機能は説明しません

39 TLS データ表現の仕方 ( 構造体, メンバー ) 構造体と同じ struct { uint8 major; uint8 minor; } ProtocolVersion; 構造体名 8bit 符号なし整数 (2 バイト ) 0 1 majaor minor ProtocolVersion version = { 3, 3 }; /* TLS v1.2*/ 0 1 0x03 0x03

40 TLS データ表現の仕方 ( 配列 エンディアン ) struct { uint32 gmt_unix_time; opaque random_bytes[28]; } Random; 32bit 符号なし整数 (4 バイト ) 1970/1/1 0:00(UTC) からの経過秒数 28 バイト長の任意のバイト列 [] の中はバイト数を表す データを書き込むときは 最上位のバイトデータをインデックスの小さい方から大きい方への順番で書き込む (big-endian/network byte order) gmt_unix_time random_bytes Mon Jul :55:29 GMT+0900 (JST) = sec = 0x55abd ab d6 81

41 TLS データ表現の仕方 ( 可変ベクター ) 0 0x00 opaque SessionID<0..32>; SessionID のサイズが 0 の場合 <> は可変ベクター型を表す 中の数字は < 最少サイズ.. 最大サイズ > 先頭にサイズを必ず入れ その後にデータが続く 先頭のサイズの領域は最大サイズが格納できる量 左の場合は最大 32 バイトだから 1 バイト (255 まで表現可能 ) 分のサイズ領域があればよい 0 1 0x01 SessionID(1 バイト ) SessionID のサイズが 1 の場合 SessionID のサイズが 32 の場合 x20 SessionID(32 バイト )

42 TLS データ表現の仕方 (enum) uint8 CipherSuite[2]; 8bit 符号なし整数が 2 バイト CipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 = { 0x00,0x40 }; 0 1 0x00 0x40 enum { null(0), (255) } CompressionMethod; CompressionMethod の値は最大 255 まで (1 バイト分 ) NULL は 0 に割り当てられています

43 TLS データ表現の仕方 ( 条件式 ) struct { ProtocolVersion client_version; Random random; SessionID session_id; CipherSuite cipher_suites<2..2^16-2>; CompressionMethod compression_methods<1..2^8-1>; select (extensions_present) { 条件式 case false: extensionが存在しなければ 空 struct {}; してれば 0~2^16-1までの可変ベクターのデータが入る case true: Extension extensions<0..2^16-1>; }; } ClientHello;

44 TLS データ表現の仕方 ( 読んでみよう ) struct { ExtensionType extension_type; opaque extension_data<0..2^16-1>; } Extension; enum { signature_algorithms(13), (65535) } ExtensionType;

45 TLS データ表現の仕方 ( 読んでみよう ) enum { none(0), md5(1), sha1(2), sha224(3), sha256(4), sha384(5), sha512(6), (255) } HashAlgorithm; enum { anonymous(0), rsa(1), dsa(2), ecdsa(3), (255) } SignatureAlgorithm; struct { HashAlgorithm hash; SignatureAlgorithm signature; } SignatureAndHashAlgorithm; SignatureAndHashAlgorithm supported_signature_algorithms<2..2^16-2>;

46 TLS データ表現の仕方 ( 読んでみよう ) struct { uint8 major; uint8 minor; } ProtocolVersion; enum { change_cipher_spec(20), alert(21), handshake(22), application_data(23), (255) } ContentType; struct { ContentType type; ProtocolVersion version; uint16 length; opaque fragment[tlsplaintext.length]; } TLSPlaintext;

47 TLS1.2 の構造 ChangeCipherSpec ( タイプ :0x14) タイプ I P ヘッダ T C P ヘッダ タイプ (4 種類 ) (1byte) TLS Record Layer (5 バイト ) バージョン (2byte) 長さ (2byte) Alert ( タイプ :0x15) レベル msg タイプ (10 種類 ) 理由 Handshake ( タイプ :0x16) 長さ (3 バイト長 ) ハンドシェイクデータ TLS Record Layer データに続いて 次の 4 種類の TLS データのいずれかが続く Application Data ( タイプ :0x17) 暗号化されたデータ msgタイプ 0x00 0x01 ハンドシェイクデータの種類 HelloRequest ClientHello 0x02 ServerHello TLS Handshake は この 10 種類に分かれる 0x0b 0x0c 0x0d Certificate ServerKeyExchange CertificateRequest 0x0e ServerHelloDone 0x0f CertificateVerify 0x10 ClientKeyExchange 0x14 Finished

48 TLS ハンドシェイクデータの構造 struct { HandshakeType msg_type; uint24 length; select (HandshakeType) { case hello_request: case client_hello: case server_hello: case certificate: HelloRequest; ClientHello; ServerHello; Certificate; case server_key_exchange: ServerKeyExchange; case certificate_request: CertificateRequest; case server_hello_done: ServerHelloDone; case certificate_verify: CertificateVerify; case client_key_exchange: ClientKeyExchange; case finished: } body; } Handshake; Finished; msg タイプ (10 種類 ) Handshake ( タイプ :0x16) 長さ (3 バイト長 ) ハンドシェイクデータ enum { hello_request(0), client_hello(1), server_hello(2), certificate(11), server_key_exchange (12), certificate_request(13), server_hello_done(14), certificate_verify(15), client_key_exchange(16), finished(20) (255) } HandshakeType; msg タイプの種類でそれぞれの構造を参照する

49 TLS ハンドシェイク まずは TLS_RSA_WITH_AES_128_GCM_SHA256 の時から

50 TLS ハンドシェイク (full handshake) ClientHello ServerHello Certificate ServerHelloDone ClientHello と ServerHello のやり取りで双方が利用する TLS バージョンや暗号化方式などを合意する ClientKeyExchange ChangeCipherSpec Finished ChangeCipherSpec Finished Application Data Application Data ( 赤文字はハンドシェイク )

51 TLS ハンドシェイク (resumption) ClientHello ServerHello ChangeCipherSpec Finished SessionID による TLS セッションの再開 鍵交換や証明書送付をスキップ ChangeCipherSpec Finished Application Data Application Data ( 赤文字はハンドシェイク ) 今回は演習の対象外です

52 TLS ハンドシェイクの意味 ClientHello/ServerHello/ServerHelloDone TLS のための情報交換バージョン 乱数 暗号方式 拡張情報 Certificate 公開鍵情報の送付エンドポイントの認証 ClientKeyExchange/ServerKeyExchange 共有鍵交換 ChangeCipherSpec 暗号開始の合図 Finished ハンドシェイクデータの改ざんチェック

53 ClientHello struct { ProtocolVersion client_version; Random random; SessionID session_id; CipherSuite cipher_suites<2..2^16-2>; CompressionMethod compression_methods<1..2^8-1>; select (extensions_present) { case false: struct {}; case true: Extension extensions<0..2^16-1>; }; } ClientHello;

54 ClientHello 項目要素サイズ先頭の長さ情報 client_version uint8 major, uint8 minor 2 N/A random uint32 gmt_unix_time, opaque random_bytes[28] N/A session_id opaque SessionID <0..32> 1 バイト分 cipher_suites uint8 CipherSuite[2] <2..2^16-2> 2 バイト分 compression_met hods null(0) <1..2^8-1> 1 バイト分 extensions extension_type(65535), extension_data<0..2^16-1> <0..2^16-1> 2 バイト分 type データ長 Extensions データ例 データ type データ 長 データ type データ 長 データ Extension 長

55 ClientHello クライアントが利用できる最高の TLS バージョンを指定 サーバがどのバージョンを使うか選択する Record Layer Handshake (ClientHello) type protocol version length (2byte) msg type length (3byte) client version random session id cipher suite compr ession Extensi on major minor major minor 0x16 0x03 0x01???? 0x01?????? 0x03 0x03 32 byte 可変可変可変可変 Version 0x03,0x00 = SSLv3 0x03,0x01= TLSv1.0 0x03,0x02=TLSv1.1 0x03,0x03=TLSv1.2

56 最小の ClientHello Record Layer Handshake (ClientHello) type protocol version length (2byte) msg type length (3byte) client version random session id cipher suite compression major minor major minor 0x16 0x03 0x01 0x00 0x2D 0x01 0x00 0x00 0x29 0x03 0x03 32 byte All 0x00 0x00 0x00,0x02 0x00,0x9c 0x01 0x00 45 byte 長 41 byte 長 CipherSuite 指定 (1 種 ) TLS1.2 用 TLS_RSA_WITH_AES_128_GCM_SHA256:0x00,0x9c ' D' + ' ' + + crypto.randombytes(32).tostring('hex') ' C0100' 本当はちゃんとした乱数を入れる

57 演習 : 最少 ClientHello を作って送る var net = require('net'); var crypto = require('crypto'); var recordheader = ' D'; var random = crypto.randombytes(32).tostring('hex'); var handshake = ' ' + random + ' C0100'; var clienthello = new Buffer(recordheader + handshake, 'hex'); var client = net.connect({host: 'tls.koulayer.com', port: 443}, function() { client.write(clienthello); }); client.on('data', function(c) { // Receive ServerHello console.log(c); });

58 ServerHello struct { ProtocolVersion server_version; Random random; SessionID session_id; 複数ではない CipherSuite cipher_suite; CompressionMethod compression_method; select (extensions_present) { case false: struct {}; case true: Extension extensions<0..2^16-1>; }; } ServerHello; 複数ではない

59 ServerHello 項目要素サイズ先頭の長さ情報 server_version uint8 major, uint8 minor 2 N/A random uint32 gmt_unix_time, opaque random_bytes[28] N/A session_id opaque SessionID <0..32> 1 cipher_suite uint8 CipherSuite[2] 2 N/A compression_met hod null(0) 1 N/A extensions extension_type, extension_data<0..2^16-1> <0..2^16-1> 2 バイト分 Record Layer(5bytes) Handshake (ServerHello) type protocol version length (2bytes) msg type length (3byte) server version major minor major minor random 32bytes session id cipher suite 2bytes compression 0x16 0x03 0x03? + 4 0x01? 0x03 0x03? 長さ 1byte 0x00,0x9c 長さ 2bytes

60 DataReader を使う データを読み込む Helper オブジェクト var DataReader = require('seccamp2015-data-reader').datareader; var reader = new DataReader(buffer); API reader.readbytes(n): 前回読み込んだ位置から n バイト分のデータをバッファで返す reader. readvector(floor, ceiling): 可変ベクターのデータを読み込み バッファで返す (floor: 最小値 ceiling: 最大値 ) reader. peekbytes(from, n): from 個目から to 個目までのバッファをコピーして返す reader. bytesremaining(): 残っているバイトサイズを返す

61 演習 : Record Header を見る function parserecordheader(reader) { var type = reader.readbytes(1).readuint8(0); var version = reader.readbytes(2); var length = reader.readbytes(2).readuintbe(0, 2); return {type: type, version: version, length: length}; } Record Layer type (1byte) protocol version length (2bytes) major (1byte) minor (1byte)

62 演習 ServerHello を見る function parseserverhello(reader) { var record_header = parserecordheader(reader); var type = reader.readbytes(1).readuint8(0); var length = reader.readbytes(3).readuintbe(0, 3); var version = reader.readbytes(2); var random = reader.readbytes(32); var session_id = reader.readvector(0, 32); var cipher = reader.readbytes(2); var compression = reader.readbytes(1); return { record_header: record_header, type: type, length: length, version: version, random: random, session_id: session_id, cipher: cipher, compression: compression }; } Handshake (ServerHello) msg type length (3byte) major server version minor random 32bytes session id cipher suite 2bytes compression

63 Certificate 最大値のみ 3 バイト分 opaque ASN.1Cert<2^24-1>; struct { 3 バイト分 ASN.1Cert certificate_list<0..2^24-1>; } Certificate; 複数の証明書データを送付 項目要素サイズ certificate_list ASN.1Cert<2^24-1> <0..2^24-1> 全証明書長証明書 #1 長証明書データ #1 証明書 #2 長証明書データ #2 最初は必ずサーバ証明書 2 つ目以降は中間証明書など

64 ここから先の演習は状態管理が必要 はじめに使った simple_tls_client.js を使います モジュールのインストール $npm install seccamp2015-data-reader seccamp2015-tls Simple TLS Client (simple_tls_client.js) の取得 $git clone $cd SecCamp2015-TLS $node simple_tls_client.js キーボードを打ってみよう ( 注 : エラー処理やサニタイジングが十分でないのであくまでテスト用で利用すること )

65 演習 Certificate を見る function parsecertificate(reader, state) { if (!checkrecordheader(reader)) return null; var record_header = parserecordheader(reader); storehandshakedata(reader, record_header.length, state); var type = reader.readbytes(1).readuint8(0); var length = reader.readbytes(3).readuintbe(0, 3); var cert_reader = new DataReader(reader.readBytes(length)); var certlist = []; while(cert_reader.bytesremaining() > 0) { var cert = cert_reader.readvector(0, 1 << 24-1); certlist.push(cert); 3バイト分 } 証明書はリストに格納 return { record_header: record_header, type: type, length: length, certlist: certlist }; }

66 ServerKeyExchange RSA 鍵交換では不要 今の時点じゃスキップします ECDHE のところで再度説明します

67 ServerHelloDone struct { } ServerHelloDone; ServerHello の終了の合図ハンドシェイクヘッダのみ handshake type handshake 長 0x0e 0x00 0x00 0x00

68 ClientKeyExchange struct { select (KeyExchangeAlgorithm) { case rsa: EncryptedPreMasterSecret; case dhe_dss: case dhe_rsa: case dh_dss: case dh_rsa: case dh_anon: ClientDiffieHellmanPublic; } exchange_keys; } ClientKeyExchange; 鍵交換のアルゴリズムによって異なる RSA による鍵交換では暗号化された PreMasterSecret を送る DH/DHE による鍵交換ではクライアントの公開鍵を送る

69 ClientKeyExchange (RSA 鍵交換の場合 ) struct { ProtocolVersion client_version; opaque random[46]; } PreMasterSecret; struct { public-key-encrypted PreMasterSecret pre_master_secret; } EncryptedPreMasterSecret; エラー処理が脆弱性がなる場合もある 通常は証明書に記載されている RSA 公開鍵で pre_master_secret を暗号化 ClientHello で送付したバージョン <0..2^16-1> の可変ベクター

70 ClientKeyExchange (RSA 鍵交換の場合 ) PreMasterSecret client version random 46bytes major 0x03 minor 0x01 Record Layer(5bytes) Handshake(ClientKeyExchange) type protocol version length (2bytes) msg type length (3byte) Encrypted PreMasterSecret major minor 0x16 0x03 0x03? + 4 0x10? 長さ 2 バイト?

71 TLS の鍵生成の流れ pre master secret ( 任意のバイト数 : 鍵交換による ) サーバ クライアント間の鍵交換方式で生成し 秘密的に共有する master secret (48 bytes) PRF(pre_master_secret, "master secret", client_random+server_random) keyblock ( 任意のバイト数 : 利用暗号方式による ) PRF(master_secret, "key expansion", server_random+client_random) client_write_mac server_write_mac client_write_key server_write_key client_write_iv server_write_iv

72 PreMasterSecret/MasterSecret TLS で利用する IV( 初期ベクトル ) 共有鍵 MAC 鍵のデータ元 MasterSecret は 48 バイト長 PreMasterSecret の長さは鍵交換方式に依存する MasterSecret は PreMasterSecret ClientRandom ServerRandom 固定ラベルから生成する Clinet/ServerRandom は全て丸見え PreMasterSecret は 必ず死守して守らないといけない これが漏えいすると TLS の安全性は全ておじゃん

73 演習 :PreMasterSecret の計算 TLS1.2 の RSA 鍵交換時 function createpremastersecretrsakeyexchange(state) { var pre_master_secret = ( ここを作る ) } return pre_master_secret;

74 演習答え :PreMasterSecret の計算 TLS1.2 の RSA 鍵交換時 (48 バイト ) function createpremastersecretrsakeyexchange(state) { var version = new Buffer('0303', 'hex'); } var pre_master_secret = Buffer.concat([version, crypto.randombytes(46)]); return pre_master_secret; ClientHello で送った Version 2 バイト分 残り 46 バイトは乱数で発生させる

75 演習 : ClientKeyExchange を作る var clientkeyexchange_json = { }; pre_master_secret: pre_master_secret, pubkey: require('fs').readfilesync( dirname + '/pubkey.pem') var clientkeyexchange = createclientkeyexchange(clientkeyexchange_json, state); 公開鍵情報は 本当は Certificate データから抽出する パーサーが必要なので別ファイルから読み込む function createclientkeyexchange(json, state) { state.handshake.clientkeyexchange_json = json; var public_key = json.pubkey; var pre_master_secret = json.pre_master_secret; var encrypted = crypto.publicencrypt({ key: public_key, 公開鍵で pre_master_secret を暗号化 padding: require('constants').rsa_pkcs1_padding }, pre_master_secret); var encrypted_pre_master_secret = writevector(encrypted, 0, 1 << 16-1); var handshake = createhandshake(handshake_type.clientkeyexchange, encrypted_pre_master_secret); return createrecord(type.handshake, handshake); };

76 MasterSecret の計算その 1: P_hash PreMasterSecret のサイズは 鍵交換方式で異なる MasterSecret は 48 バイト必要 P_hash: データ拡張関数 ある secret を必要なサイズまで伸長させる P_hash(secret, seed) = HMAC_hash(secret, A(1)+seed) + HMAC_hash(secret, A(2)+seed) +. ( 必要なサイズまで伸長 ) A(0) = seed; A(i) = HMAC_hash(secret, A(i-1)) + はデータの結合を表す HMAC_hash のアルゴリズムは TLS1.2 では SHA256 を使う ( それ以前は MD5/SHA-1 の組み合わせ )

77 演習 : TLS1.2 の P_hash を作る var crypto = require('crypto'); var P_hash = require('seccamp2015-tls').p_hash; var algo = 'sha256'; var secret = 'mysecret'; var seed = (new Buffer(32)).fill(0); var size = 48; function MyP_hash(algo, secret, seed, size) { var ret = new Buffer(size); ( ここを作る ) return ret; } var answer = P_hash(algo, secret, seed, size); var my_answer = MyP_hash(algo, secret, seed, size); console.log(answer); console.log(my_answer); console.log(answer.equals(my_answer));

78 演習 : 答え HMAC_hash(secret, A(i)+seed) サイズ分まで結合する次のA(i) を計算 function MyP_hash(algo, secret, seed, size) { var ret = new Buffer(size); var hmac = crypto.createhmac(algo, secret); hmac.update(seed); A(0) はseed var a = hmac.digest(); // A(1) var end = 0; A(1) を計算 while(size > end) { hmac = crypto.createhmac(algo, secret); hmac.update(buffer.concat([a, seed])); var b = hmac.digest(); var len = (size - end >= b.length)? b.length: size - end; b.copy(ret, end, 0, len); end += len; hmac = crypto.createhmac(algo, secret); hmac.update(a); a = hmac.digest(); // A(i+1) } return ret; }

79 MasterSecret の計算その 2 PRF(PseudoRandom Function) PRF(secret, label, seed) = P_hash(secret, label + seed) master_secret = PRF(pre_master_secret, "master secret", ClientHello.random + ServerHello.random) [0..47]; 48 バイトまで計算 固定ラベル = P_hash(pre_master_secret, "master secret" + ClientHello.random +ServerHello.random)[0..47] 重要 :PRFはTLSで他にも様々な要素の計算に用いられます

80 演習 : TLS1.2 master_secret を計算する var crypto = require('crypto'); var PRF12 = require('seccamp2015-tls').prf12; var pre_master_secret = crypto.randombytes(48); var client_random = crypto.randombytes(32); var server_random = crypto.randombytes(32); label と seed を結合して新しい seed を生成 function MyPRF12(secret, label, seed, size) { return MyP_hash('sha256', secret, Buffer.concat([label, seed]), size); } ラベルは master secret master_secret は 48 バイト var label = new Buffer("master secret"); var master_secret = PRF12(pre_master_secret, label, Buffer.concat([client_random, server_random]), 48); var Mymaster_secret = MyPRF12(pre_master_secret, label, Buffer.concat([client_random, server_random]), 48); console.log(master_secret); console.log(mymaster_secret); console.log(master_secret.equals(mymaster_secret));

81 KeyExpansion TLS で必要な鍵は MAC 用 共有鍵用 初期ベクトル (IV) 用の 3 種類 Client/Server それぞれが必要なので 6 つ必要 それぞれで必要なサイズは暗号方式で異なる TLS で必要な鍵は 48 バイトの MasterSecret では サイズが足りない MasterSecret から PRF で必要なサイズの key_block に伸長させる master_secret(48 バイト ) 注意!:master_secret の計算時と順番が逆 key_block = PRF(master_secret, "key expansion", server_random + client_random); client_write_mac server_write_mac client_write_key server_write_key client_write_iv server_write_iv

82 KeyExpansion(AES-128-GCM) client_write_mac, server_write_mac: 0バイトx2 (AEADはMAC 不要 ) client_write_key, server_write_key: 16バイトx2 (128bits 鍵長 ) client_write_iv, server_write_iv: 4バイトx2 (12バイト中の頭 後述) 合計 : 40バイト key_block = PRF12(algo, master_secret, "key expansion", ServerHello.random+ClientHello.random, 40); client_write_key(16bytes) server_write_key(16bytes) client_write _IV(4bytes) server_write _IV(4bytes)

83 演習 :KeyBlock の計算 function KDF(pre_master_secret, client_random, server_random) { var master_secret = PRF12(pre_master_secret, "master secret", Buffer.concat([client_random, server_random]), 48); // 40 bytes key_block for AES-128-GCM var key_block_reader = new DataReader( ラベルは key expansion PRF12(master_secret, "key expansion", Buffer.concat([server_random, client_random]), 40)); AES-128-GCM は 40 バイト分必要 return { } }; master_secret: master_secret, client_write_mac_key: null, server_write_mac_key: null, client_write_key: key_block_reader.readbytes(16), server_write_key: key_block_reader.readbytes(16), client_write_iv: key_block_reader.readbytes(4), server_write_iv: key_block_reader.readbytes(4) GCM は MAC はいらない 結合の順番が反対 AES-128 の秘密鍵は 16 バイト 初期ベクトルの最初の 4 バイト分は両者で秘密共有 残り 8 バイトはフレームに付加して送る

84 ChangeCipherSpec struct { enum { change_cipher_spec(1), (255) } type; } ChangeCipherSpec; 送信元が暗号開始を宣言 これを送信した後は暗号通信を行う Record Layer ChangeCipherSpec ContentType Version length major minor (2byte) 0x14 0x03 0x03 0x00 0x01 0x01

85 Finished struct { opaque verify_data[verify_data_length]; } Finished; 12 バイト固定 これまでのハンドシェイクデータ ( ただし自分は除く ) のハッシュを計算 TLS1.2 では SHA256 を使う verify_data = PRF(master_secret, finished_label, Hash(handshake_messages))[0..11]; finished_label: クライアントは "client finished" サーバは "server finished" Finished を受信すると これまで送受信したハンドシェイクデータから計算した値と比較 ハンドシェイクデータが改ざんされてないことを確認する

86 Finished を作る var clientfinished = { master_secret: state.keyblock.master_secret, handshake_message_list: state.handshake_message_list }; var clientfinished = createclientfinished(clientfinished, state); これまで交換したハンドシェイクデータのリスト function createclientfinished(json, state) { state.handshake.clientfinished = json; これまで交換したハンドシェイクデータの // create session hash ハッシュ値を求める var shasum = crypto.createhash('sha256'); shasum.update(buffer.concat(json.handshake_message_list)); var message_hash = shasum.digest(); var r = PRF12(json.master_secret, "client finished", message_hash, 12); var handshake = createhandshake(handshake_type.finished, r); return createrecord(type.handshake, handshake); フレーム作 } 成後暗号化 PRF で 12 バイト分に切り詰める 受信した Finished 中の値と比較して改ざんチェック

87 データの暗号化 struct { ContentType type; ProtocolVersion version; uint16 length; select (SecurityParameters.cipher_type) { case stream: GenericStreamCipher; case block: GenericBlockCipher; case aead: GenericAEADCipher; } fragment; } TLSCiphertext; Record Layer レコードフィールド 暗号化した後の長さ ContentType Version length major minor (2byte) ストリーム暗号 ブロック暗号 AEAD で構造が変わる 暗号化されたデータ 0x03 0x03..

88 データの暗号化 (AEAD) struct { opaque nonce_explicit[record_iv_length]; aead-ciphered struct { }; opaque content[tlscompressed.length]; } GenericAEADCipher; key block から生成した 4bytes struct { opaque salt[4]; opaque nonce_explicit[8]; } GCMNonce; 毎回生成する乱数 (8bytes 丸見え ) 認証データ TLS レコード層の情報 additional_data = seq_num + TLSCompressed.type + TLSCompressed.version + TLSCompressed.length; uint16 0 から始まる 暗号化する前の長さ AEADEncrypted = AEAD-Encrypt(write_key, nonce, plaintext, additional_data)

89 AEAD(AES-128-GCM) で暗号化されたデータ Cont entty pe Record Header major Version minor length (2byte) explicit nonce (8 byte) 暗号化されたデータ tag (16 bytes) 0x03 0x03 explicit nonce 暗号データ tag を合わせた長さに再計算 AAD writeseq + Record Header 暗号化する平文 初期ベクトル writeiv(4bytes) + explicit nonce(8bytes) AES-128-GCM write_key 暗号化されたデータ tag

90 アプリケーションデータの暗号化 function EncryptAEAD(frame, state) { var key = state.keyblock.client_write_key; var iv = Buffer.concat([state.keyblock.client_write_IV.slice(0,4), state.nonce_explicit]); var record_header = frame.slice(0, 5); var aad = Buffer.concat([state.write_seq, record_header]); var ret = Encrypt(frame.slice(5), key, iv, aad); var encrypted = ret.encrypted; var tag = ret.tag; 初期ベクトルは write_iv(4) と explicit nonce を合わせたもの // re-calcuate length with adding nonce_explit and tag length var length = state.nonce_explicit.length + encrypted.length + tag.length; record_header.writeuintbe(length, 3, 2); record 長の再計算 // increment write sequence number incseq(state.write_seq); sequence no を増加 return Buffer.concat([record_header, state.nonce_explicit, encrypted, tag]); }

91 秘密鍵漏洩の脅威 TLS_RSA_WITH_AES_128_GCM_SHA256 は 鍵交換 署名に RSA を利用している 通信経路に pre_master_secret を暗号化して相手に送信 公開鍵 秘密鍵共に長期に固定化されている 暗号強度が低い又は秘密鍵が漏えいしてしまうとどうなるか?

92 演習 : TLS を破る 時間があれば行います サーバの秘密鍵をお渡しします 秘密鍵とハンドシェイクデータから暗号化されたアプリ通信を解読する

93 演習 : TLS を破る 秘密鍵のパスワードは口頭でお伝えします 戻し方 $ openssl rsa -in server_encrypted.key -out server.key Enter pass phrase for server_encrypted.key: writing RSA key 秘密鍵と handshake.json のデータから暗号化された Application Data を復号してください

94 演習回答 : Client/Server Random の取得 Record Layer Handshake (ClientHello) type protocol version length (2byte) msg type length (3byte) client version random session id cipher suite compr ession Extensi on major minor major minor 0x16 0x03 0x01???? 0x01?????? 0x03 0x03 32 byte 可変可変可変可変 type Record Layer(5bytes) protocol version 5+4+2=11bytes 先から 32byte 暗号化された pre master secret の取得 major minor length (2bytes) msg type length (3byte) Handshake(ClientKeyExchange) Encrypted PreMasterSecret 0x16 0x03 0x03? + 4 0x10? 長さ 2 バイト? 5+4+2=11bytes 先から最後まで 秘密鍵で復号化

95 演習回答 : ここを復号化して平文をゲットする Cont entty pe Record Header major Version minor length (2byte) explicit nonce (8 byte) 暗号化されたデータ tag (16 bytes) 0x03 0x03 sequence no と合わせて AAD ただし長さは再計算が必要 writeiv と合わせて IV 復号化でセットするタグ値

96 演習回答 :solve.js var DataReader = require('seccamp2015-data-reader').datareader; var SecCampTLS = require('seccamp2015-tls'); var fs = require('fs'), crypto = require('crypto'); var handshake = require( dirname + '/handshake.json'); var clienthello = new Buffer(handshake.ClientHello, 'hex'); var serverhello = new Buffer(handshake.ServerHello, 'hex'); var clientkeyexchange = new Buffer(handshake.ClientKeyExchange, 'hex'); var encryptedapplicationdata = new Buffer(handshake.EncryptedApplicationData, 'hex'); // obtain handshake parameters var client_random = clienthello.slice(11, 11+32); var server_random = serverhello.slice(11, 11+32); var encrypted_pre_master_secret = clientkeyexchange.slice(11); // obtain private key var private_key = fs.readfilesync( dirname + '/server.key'); JSON データからハンドシェイクデータを抽出 ハンドシェイクパラメータを抽出 秘密鍵の入手

97 演習回答 : // decrypt pre master secret var pre_master_secret = crypto.privatedecrypt( {key: private_key, padding: require('constants').rsa_pkcs1_padding }, encrypted_pre_master_secret); // objtain keyblock 秘密鍵を使って ClientKeyExchange で暗号化された pre master secret の復号化 pre master secret と client/server random を使って key block を生成 var keyblock = SecCampTLS.KDF(pre_master_secret, client_random, server_random); // Calculate Sequence Number var read_seq = (new Buffer(8)).fill(0); read_seq[7] = 0x01; sequence number を生成

98 演習回答 : var reader = new DataReader(encryptedApplicationData); // Obtain AEAD parameters var record_header = reader.readbytes(5); var length = record_header.readuintbe(3, 2); var frame = reader.readbytes(length); var nonce_explicit = frame.slice(0, 8); var encrypted = frame.slice(8, frame.length - 16); var tag = frame.slice(-16); // Re-Caluclate record header record_header.writeuintbe(encrypted.length, 3, 2); record header の長さ再計算 暗号化されたアプリケーションデータから AEAD パラメータを抽出する var iv = Buffer.concat([keyblock.client_write_IV, nonce_explicit]); var aad = Buffer.concat([read_seq, record_header]);

99 演習回答 : // Decrypt Application Data var decipher = crypto.createdecipheriv('aes-128-gcm', keyblock.client_write_key, iv); decipher.setauthtag(tag); decipher.setaad(aad); var clear = decipher.update(encrypted); decipher.final(); console.log(clear.tostring()); これまで得られたパラメータからデータの復号化 平文の取得

100 Perfect Forward Secrecy TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 を使う

101 Perfect Forward Secrecy(PFS) 前方秘匿性 セッション毎に一時的な鍵を使う ハンドシェイクを含む全暗号データを取得されているような状況でも 将来的な秘密鍵漏洩などのリスクに対応する TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 Ephemeral: 一時的な鍵交換手法

102 ECDHE のハンドシェイク ClientHello 拡張を追加 Client の公開鍵を送付 ClientHello + elliptic_curves(10) + ec_point_formats(11) ClientKeyExchange ChangeCipherSpec Finished 使える楕円曲線名と ECPoint 書式を通知 ECPoint の書式を合意 Application Data ServerHello + ec_point_formats(11) Certificate ServerKeyExchange ServerHelloDone ChangeCipherSpec Finished ServerHello 拡張を追加 楕円曲線名と Server の公開鍵を署名付きで送付 ( 赤文字が追加変更されるところ )

103 ECDHE ClientHello 拡張 struct { NamedCurve elliptic_curve_list<1..2^16-1> } EllipticCurveList; enum { sect163k1 (1), 省略, secp256r1 (23), 省略, (0xFFFF) } NamedCurve; クライアントがサポートしている楕円曲線のリストをサーバ側に通知 サーバはリストの中から適切な楕円曲線を選び ServerKeyExchange 内で選択した楕円曲線を通知する elliptic_curves(10) リスト長データ長 secp256r1 (23) 0x00 0x0a 0x00 0x04 0x00 0x02 0x00 0x17

104 ECDHE Client/Server Hello 拡張 enum { uncompressed (0), 省略, reserved ( ) } ECPointFormat; struct { 楕円暗号の公開鍵の書式 ECPointFormat ec_point_format_list<1..2^8-1> } ECPointFormatList; ec_point_formats(11) リスト長データ長 uncompressed(0) 0x00 0x0b 0x00 0x02 0x01 0x00

105 ECDHE ServerKeyExchange select (KeyExchangeAlgorithm) { case ec_diffie_hellman: ServerECDHParams params; Signature signed_params; } ServerKeyExchange; struct { ECParameters curve_params; ECPoint public; } ServerECDHParams; struct { SignatureAndHashAlgorithm algorithm; opaque signature<0..2^16-1>; } DigitallySigned; RSA 秘密鍵で ServerECDHParms と Random を署名 ServerECDHParams ECParameters ECPoint algorithm curve_type named_curve 長さ public key named_curve (3) secp256r1 (23) (Hello 拡張指定の書式 ) RSA-SHA256 (0x04,0x01) Signature signature signature = sign(algorithm, ClientHello.random + ServerHello.random + ServerECDHParams);

106 ECDHE ClientKeyExchange struct { select (KeyExchangeAlgorithm) { case ec_diffie_hellman: ClientECDiffieHellmanPublic; } exchange_keys; } ClientKeyExchange; ECDHEは explicit struct { select (PublicValueEncoding) { case implicit: struct { }; case explicit: ECPoint ecdh_yc; } ecdh_public; } ClientECDiffieHellmanPublic; 長さ ClientECDHParams ECPoint public key (Hello 拡張指定の書式 ) ClientKeyExchange は署名の必要はない

107 演習 : ECDHE 公開鍵の守られ方の違い ServerKeyExchange: 公開鍵を署名 ClientKeyExchange: やりたい放題 どうしてでしょう?

108 TLS 最新情報 TLS1.3(*) とはどういうものか? (* 注 : 時点のものです 最終仕様で変更になる可能性があります )

109 TLS1.3(*) の背景 2008 年 TLS1.2 仕様化から 7 年 古い暗号やプロトコルの危殆化に伴う機能の抜本的な見直し 常時 TLS 化を目指し 将来的に安心で強固なセキュリティの必要性 モバイル環境の普及や Web アプリの高度化に伴う高パフォーマンス 低レイテンシー化要望の高まり

110 TLS1.3 の目的 1. ハンドシェイクデータをできるだけ暗号化して隠匿する 2. ハンドシェイクレイテンシーの削減 再接続の場合は 0-RTT フルハンドシェイクは 1-RTT 3. ハンドシェイクで交換する項目の見直し 4. レコード層暗号化の見直し (RC4 廃止 CBC の不採用 )

111 TLS1.3 の構造 (*) Alert ( タイプ :0x15) レベル 理由 ChangeCipherSpec を廃止 I P ヘッダ T C P ヘッダ タイプ (4 種類 ) (1byte) TLS Record Layer (5 バイト ) バージョン 0x0301 に固定 (2byte) 長さ (2byte) msg タイプ (10 種類 ) Handshake ( タイプ :0x16) 長さ Application Data ( タイプ :0x17) 暗号化されたデータ ハンドシェイクデータ msg タイプ ハンドシェイクデータの種類 0x00 reserved( 旧 HelloRequest 廃止 ) Extens ion ID 0x00d TBD TBD TBD TBD TBD Extension signature_algorithms early_data supported_groups known_configration pre_shared_key client_key_shares Early Handshake ( タイプ :0x19) msg タイプ長さハンドシェイクデータ TLS Handshake は この 12 種類に増加 後方互換のため 3 つは予約 (* 注 : 時点のものです 最終仕様で変更になる可能性があります ) 0x01 0x02 0x04 0x06 0x07 0x0b ClientHello ServerHello NewSessionTicket HelloRetryRequest ServerKeyShare Certificate 0x0c reserved( 旧 ServerKeyExchange 廃止 ) 0x0d 0x0e 0x0f CertificateRequest ServerConfigration CertificateVerify 0x10 reserved( 旧 ClientKeyExchange 廃止 ) 0x14 Finished

112 TLS1.3 ハンドシェイク (full handshake) ClientHello + ClientKeyShare Finished Application Data Application Data ここで即暗号化 ServerHello ServerKeyShare EncryptedExtensions ServerConfigration Certificate Finished Application Data 1-RTT ( 赤文字は暗号化されているデータ )

113 TLS1.3 ハンドシェイク ( 鍵交換ができなかった時 ) ClientHello + ClientKeyShare ClientHello + ClientKeyShare Finished Application Data Application Data HelloRetryRequest ServerHello ServerKeyShare EncryptedExtensions ServerConfigration Certificate Finished Application Data ここで即暗号化 2-RTT ( 赤文字は暗号化されているデータ )

114 TLS1.3 ハンドシェイク ( 再接続 ) 以前のサーバ公開鍵と組み合わせてフライイングでアプリデータ暗号化して送る ClientHello + ClientKeyShare + KnownConfigration + EarlyDataIndication ApplicationData Finished ServerHello + KnownConfigration + EarlyDataIndication ServerKeyShare Finished Application Data Application Data 0-RTT ( 赤文字は暗号化されているデータ )

115 TLS1.3 0-RTT の問題点 0-RTT ApplicationData POST / HTTP/1.1 xxxx Reply 攻撃 更新 クラスタリング厳密な同期は不可能 0-RTT ApplicationData POST / HTTP/1.1 xxxx 更新 Reply 攻撃に弱いため 最初のデータは冪等性のあるリクエストのみに制限しなければならない

116 TLS1.3 鍵生成 (Server view) DH or ECDH 鍵交換 ClientPubKey Server SecretKey in ClientKeyShare Client PubKey in ClientKeyShare DH or ECDH 鍵交換 Server SecretKey in KnownConfigration Ephemeral Secret Static Secret 以前に送付した古いの 最初なら鍵生成したもの HKDF xes xss HKDF HKDF(label + session_hash) HKDF key HKDF seed Master Secret Handshake Traffic Keys ハンドシェイク暗号化用 Exporter Secret Resumption Secret Application Finished Traffic Keys Secret アプリデータ暗号化用 Finished 用 Early Data Traffic Keys

117 TSL1.3 変更点まとめ (*) Compression, Renegotiationの廃止 ChangeCipherSpec 廃止 ClientKeyExchange 廃止してClientHelloの拡張フィールドに HelloRequest/ServerHello 廃止 Record 層のバージョンを 0x03,0x03(TLS1.0) に固定 ServerConfigrationをクライアントに渡し 0-RTT 接続を実現 ServerKeyShare 後即暗号化 証明書データも隠匿 乱数から時間の gmt フィールド廃止 (* 注 : 時点のものです 最終仕様で変更になる可能性があります )

118 TSL1.3 変更点まとめ (*) 鍵交換は名前付き DH,ECDH で ephemeral 利用のみ 鍵生成は HKDF 利用に変更 Ephemeral/Static の 2 種類の secret から session_hash を付けて各用途別に生成 暗号モードで利用できるのは AEAD のみ (GCM, CCM, Poly1305) AEAD の初期ベクタ廃止 Record 層の Length を AEAD で認証外に 他にも色々 (* 注 : 時点のものです 最終仕様で変更になる可能性があります )

HTTP/2, QUICからTLS1.3へ

HTTP/2, QUICからTLS1.3へ HTTP/2, QUIC から TLS1.3 へ 大津繁樹 株式会社インターネットイニシアティブ (IIJ) Internet Week 2015 2015/11/18 2015 年 11 月 19 日更新版 自己紹介 大津繁樹 株式会社インターネットイニシアティブ (IIJ) プロダクト本部アプリケーション開発部サービス開発 2 課 Node.JS Technical Steering Committee

More information

TLS 1.2 TLS TLS iijlab-seminar pd

TLS 1.2 TLS   TLS iijlab-seminar pd TLS 1.3 2018.2.14 @kazu_yamamoto 1 TLS 1.2 TLS https://www.iij.ad.jp/dev/report/iir/031/03_01.html TLS 1.3 http://seminar-materials.iijlab.net/iijlab-seminar/ iijlab-seminar-20170110.pdf HTTPS SEO https://employment.en-japan.com/engineerhub/

More information

2.SSL/TLS と暗号プロトコルの安全性 恒久的に噴出する脆弱性との戦い クライアント ClientKeyExchange Verify ServerKeyExchange Request Done Request サーバ X Master Secret CCS MAC 図 -1 図

2.SSL/TLS と暗号プロトコルの安全性 恒久的に噴出する脆弱性との戦い クライアント ClientKeyExchange Verify ServerKeyExchange Request Done Request サーバ X Master Secret CCS MAC 図 -1 図 小特集暗号と社会の素敵な出会い 2.SSL/TLS と暗号プロトコルの安全性 恒久的に噴出する脆弱性との戦い 基応専般 須賀祐治 (( 株 ) インターネットイニシアティブ / 筑波大学 ) SSL Secure Socket Layer /TLS Transport Layer Security SSL/TLS TLS TLS IETF Internet Engineering Task Force

More information

fun H(bitstring): bitstring. (* SHA1 *) fun P_hash(bitstring, bitstring): bitstring. (* P_SHA1 *) reduc forall secret: bitstring, label: bitstring, se

fun H(bitstring): bitstring. (* SHA1 *) fun P_hash(bitstring, bitstring): bitstring. (* P_SHA1 *) reduc forall secret: bitstring, label: bitstring, se 暗号プロトコル評価結果 独立行政法人情報通信研究機構 1. プロトコル名 :EAP-TLS 2. 関連する標準 IETF:RFC2716 (http://www.ietf.org/rfc/rfc2716.txt) 3. 使用したツール :Proverif 4. 評価の概要 :Proverif による評価では 攻撃は発見されなかった 5.ProVerif による評価 以下では ロール S(Authenticator)

More information

調査結果詳細 本書は SSL/TLS アプライアンス製品の暗号設定方法等の調査報告書 の 1 部分を取り出したもの である 調査の背景 調査方法等は報告書を参考にされたい 1.x.1 章記載の表 1.x.1-1 暗号設定内容 ( デフォルト ) の見方を以下に示す CipherSuite 選択優先権

調査結果詳細 本書は SSL/TLS アプライアンス製品の暗号設定方法等の調査報告書 の 1 部分を取り出したもの である 調査の背景 調査方法等は報告書を参考にされたい 1.x.1 章記載の表 1.x.1-1 暗号設定内容 ( デフォルト ) の見方を以下に示す CipherSuite 選択優先権 Barracuda WAF モデル 360 SSL/TLS アプライアンス製品の暗号設定方法等の調査報告書 調査結果詳細 本書は SSL/TLS アプライアンス製品の暗号設定方法等の調査報告書 の 1 部分を取り出したもの である 調査の背景 調査方法等は報告書を参考にされたい 1.x.1 章記載の表 1.x.1-1 暗号設定内容 ( デフォルト ) の見方を以下に示す CipherSuite 選択優先権

More information

調査結果詳細 本書は SSL/TLS アプライアンス製品の暗号設定方法等の調査報告書 の 1 部分を取り出したもの である 調査の背景 調査方法等は報告書を参考にされたい 1.x.1 章記載の表 1.x.1-1 暗号設定内容 ( デフォルト ) の見方を以下に示す CipherSuite 選択優先権

調査結果詳細 本書は SSL/TLS アプライアンス製品の暗号設定方法等の調査報告書 の 1 部分を取り出したもの である 調査の背景 調査方法等は報告書を参考にされたい 1.x.1 章記載の表 1.x.1-1 暗号設定内容 ( デフォルト ) の見方を以下に示す CipherSuite 選択優先権 Barracuda Load Balancer ADC モデル 340 SSL/TLS アプライアンス製品の暗号設定方法等の調査報告書 調査結果詳細 本書は SSL/TLS アプライアンス製品の暗号設定方法等の調査報告書 の 1 部分を取り出したもの である 調査の背景 調査方法等は報告書を参考にされたい 1.x.1 章記載の表 1.x.1-1 暗号設定内容 ( デフォルト ) の見方を以下に示す

More information

PowerPoint プレゼンテーション

PowerPoint プレゼンテーション 1 SSLWatcher: SSL/TLS 通信を監視し警告するハイパバイザ 平井成海 電気通信大学 目次 1 研究背景 目的と方針 2 SSL/TLSの概要 3 システムの設計 4 システムの実装 5 デモと実験 6 関連研究 7 まとめと今後の課題 2 目次 1 研究背景 目的と方針 2 SSL/TLSの概要 3 システムの設計 4 システムの実装 5 デモと実験 6 関連研究 7 まとめと今後の課題

More information

IPsec徹底入門

IPsec徹底入門 本資料について 本資料は下記書籍を基にして作成されたものです 文章の内容の正確さは保障できないため 正確な知識を求める方は原文を参照してください 書籍名 :IPsec 徹底入門著者 : 小早川知明発行日 :2002 年 8 月 6 日発売元 : 翔泳社 1 IPsec 徹底入門 名城大学理工学部渡邊研究室村橋孝謙 2 目次 第 1 章 IPsec アーキテクチャ 第 2 章 IPsec Security

More information

今後の予定 第 10 回 :6 月 22 日 暗号化ソフトウェア :SSL,SSH 第 11 回 :6 月 29 日 サーバセキュリティ 第 12 回 :7 月 6 日 理論 : 計算論, 暗号プロトコル 第 13 回 :7 月 13 日 企業 組織のセキュリティ :ISMS, 個人情報保護法 第

今後の予定 第 10 回 :6 月 22 日 暗号化ソフトウェア :SSL,SSH 第 11 回 :6 月 29 日 サーバセキュリティ 第 12 回 :7 月 6 日 理論 : 計算論, 暗号プロトコル 第 13 回 :7 月 13 日 企業 組織のセキュリティ :ISMS, 個人情報保護法 第 情報セキュリティ 第 10 回 :2007 年 6 月 22 日 ( 金 ) 今後の予定 第 10 回 :6 月 22 日 暗号化ソフトウェア :SSL,SSH 第 11 回 :6 月 29 日 サーバセキュリティ 第 12 回 :7 月 6 日 理論 : 計算論, 暗号プロトコル 第 13 回 :7 月 13 日 企業 組織のセキュリティ :ISMS, 個人情報保護法 第 14 回 :7 月 20

More information

MPX8005c SSL/TLS アプライアンス製品の暗号設定方法等の調査報告書

MPX8005c SSL/TLS アプライアンス製品の暗号設定方法等の調査報告書 MPX8005c SSL/TLS アプライアンス製品の暗号設定方法等の調査報告書 調査結果詳細 本書は SSL/TLS アプライアンス製品の暗号設定方法等の調査報告書 の 1 部分を取り出したもの である 調査の背景 調査方法等は報告書を参考にされたい 1.x.1 章記載の表 1.x.1-1 暗号設定内容 ( デフォルト ) の見方を以下に示す CipherSuite 選択優先権 プロトコル設定状況

More information

pkiday_tls13.key

pkiday_tls13.key ClientHello ClientKeyExchange ChangeCipherSpec Finished Application Data ServerHello Certificate ServerHelloDone ChangeCipherSpec Finished Application Data ClientHello Finished Application Data ServerHello

More information

C02.pdf

C02.pdf / 1999 12 14 Internet Week 99 Internet Week 99 1999 Yu Inamura, Japan Network Information Center 1 2 2000 1. 2. 3. 4. 1976 5. 1993 2.1 N!! N 2.2 1976 Shannon ConfusionDiffusion 2 SPN Substitution Permutation

More information

SSL 安 全 性 調 査 報 告 書 改 訂 第 2 版 2004 年 2 月 6 日 ( 株 )KDDI 研 究 所 1

SSL 安 全 性 調 査 報 告 書 改 訂 第 2 版 2004 年 2 月 6 日 ( 株 )KDDI 研 究 所 1 2 SSL 安 全 性 調 査 報 告 書 改 訂 第 2 版 2004 年 2 月 6 日 ( 株 )KDDI 研 究 所 1 2 3 目 次 0. はじめに...7 1. SSL/TLS の 比 較...9 1.1. SSL 3.0 の 概 要... 9 1.1.1. SSL レイヤ 構 造... 9 1.1.2. CipherSpec/SecurityParameters... 12 1.1.3.

More information

情報セキュリティ 第 9 回 :2007 年 6 月 15 日 ( 金 )

情報セキュリティ 第 9 回 :2007 年 6 月 15 日 ( 金 ) 情報セキュリティ 第 9 回 :2007 年 6 月 15 日 ( 金 ) 本日学ぶこと 信頼される第三者 を用いないセキュリティ Diffie-Hellman 鍵交換 PGP,GnuPG Diffie-Hellman 鍵交換により, 認証局なしに鍵となる値を共有できる. ただし man-in-the-middle 攻撃に弱い. PGP では, 誰をどの程度信頼するかは各ユーザが設定する. 2 Diffie-Hellman

More information

IPCOM EX (IPCOM EX IN ソフトウェア V01) SSL/TLS アプライアンス製品の暗号設定方法等の調査報告書

IPCOM EX (IPCOM EX IN ソフトウェア V01) SSL/TLS アプライアンス製品の暗号設定方法等の調査報告書 IPCOM EX2-3500 (IPCOM EX2-3000 IN ソフトウェア V01) SSL/TLS アプライアンス製品の暗号設定方法等の調査報告書 調査結果詳細 調査の背景 調査方法等は SSL/TLS を利用するサーバアプライアンス製品における暗号設定方法 等の調査報告書 を参考にされたい 1.1.1 章記載の表 1.1.1-1 暗号設定内容 ( デフォルト ) の見方を以下に示す CipherSuite

More information

Microsoft PowerPoint pptx

Microsoft PowerPoint pptx 情報セキュリティ 第 10 回 2015 年 6 月 12 日 ( 金 ) 1/24 本日学ぶこと 本日の授業を通じて インターネットにおける通信を暗号化するソフトウェアについて学びます. HTTPSほかの暗号化を支える SSL/TLS について, その構成や運用方法などを理解します. 安全なリモートログインを実現する SSH について, ログインまでの手順を中心に学習します. 2 PGP,SSL/TLS,SSH

More information

TLS/SSLの暗号利用に関する現状と課題

TLS/SSLの暗号利用に関する現状と課題 TLS/SSL の暗号利用に関する 現状と課題について NTT 情報流通プラットフォーム研究所情報セキュリティプロジェクト神田雅透 Internet Week 2008 にて どのように変わったか? ( あるいは変わらなかったか?) SSL/TLS は暗号化技術? 暗号化は SSL で の一言で片づけられていないか ~ どんな暗号を使っているか認識されていないのに 適切な設定 がなされているか ~

More information

Microsoft PowerPoint pptx

Microsoft PowerPoint pptx 情報セキュリティ 第 8 回 2016 年 6 月 3 日 ( 金 ) 1/20 本日学ぶこと 本日の授業を通じて 鍵 の生成 配送 認証 破棄について, その必要性と方法を理解します. セキュリティを実現するために必要となる, 乱数 の性質と, 具体的な乱数生成アルゴリズムを学びます. 公開鍵暗号とディジタル署名を円滑に運用するための, 公開鍵基盤 (PKI) について学びます. 2 鍵は重要 鍵は小さい

More information

Microsoft PowerPoint - IPsec徹底入門.ppt

Microsoft PowerPoint - IPsec徹底入門.ppt 本資料について 本資料は下記論文を基にして作成されたものです. 文書の内容の正確さは保障できないため, 正確な知識を求める方は原文を参照してください. 著者 : 小早川知明 論文名 : IPsec 徹底入門 発表日 : 2002 年 8 月 6 日 2006/04/10 1 IPsec 徹底入門 発表者 渡邊研究室 030432017 今村圭佑 目次 第一章 IPsec アーキテクチャ 第二章 IPsec

More information

Microsoft PowerPoint pptx

Microsoft PowerPoint pptx 情報セキュリティ 第 4 回 2011 年 5 月 13 日 ( 金 ) 1/24 本日学ぶこと 使い捨てパッド DES (Data Encryption Standard) AES (Advanced Encryption Standard) ブロック暗号のモード 2 ( 復習 ) 暗号系 平文 平文 暗号化 暗号化鍵 復号鍵 復号 盗聴可能な通信路 暗号文 暗号文 3 ( 復習 ) 単一換字暗号

More information

ATS の概要とCloudFrontの対応状況CloudFrontのSSL機能

ATS の概要とCloudFrontの対応状況CloudFrontのSSL機能 まだ間に合う! Amazon CloudFront で ATS 対応 アマゾンウェブサービスジャパン株式会社 事業開発部 三宅琢也 Agenda 背景 : HTTPSの利用の加速 ATSとCloudFrontの対応状況 ATS 対応におけるCloudFrontのメリット まとめ 背景 : HTTPS の利用の加速 HTTPS とは? Hyper Text Transfer Protocol Secure

More information

注意事項 本文書は 2014 年 10 月 15 日時点で公開されている脆弱性情報にもとづいて作成されています 脆弱性の影響を受ける条件 改善策及び回避策等は公開情報をもとに記載しており 今後新 たに公開される情報により変更される可能性がありますのでご注意ください 目 次 1. 脆弱性の概要...

注意事項 本文書は 2014 年 10 月 15 日時点で公開されている脆弱性情報にもとづいて作成されています 脆弱性の影響を受ける条件 改善策及び回避策等は公開情報をもとに記載しており 今後新 たに公開される情報により変更される可能性がありますのでご注意ください 目 次 1. 脆弱性の概要... SSL 3.0 の脆弱性に関する注意喚起 rev1.0 平成 26 年 10 月 15 日 株式会社ファイブドライブ 100-0011 東京都千代田区内幸町 1-1-7 TEL:03-5511-5875/FAX:03-5512-5505 注意事項 本文書は 2014 年 10 月 15 日時点で公開されている脆弱性情報にもとづいて作成されています 脆弱性の影響を受ける条件 改善策及び回避策等は公開情報をもとに記載しており

More information

Copyright 2014 Symantec Corporation. All rights reserved. Symantec と Symantec ロゴは Symantec Corporation または関連会社の米国およびその他の国における登録商標です その他の会社名 製品名は各社の登録商

Copyright 2014 Symantec Corporation. All rights reserved. Symantec と Symantec ロゴは Symantec Corporation または関連会社の米国およびその他の国における登録商標です その他の会社名 製品名は各社の登録商 WHITE PAPER: White Paper SSL を理解するための基礎ネゴシエーション 暗号化通信がはじまるまで powered by Symantec Copyright 2014 Symantec Corporation. All rights reserved. Symantec と Symantec ロゴは Symantec Corporation または関連会社の米国およびその他の国における登録商標です

More information

¥Í¥Ã¥È¥ï¡¼¥¯¥×¥í¥°¥é¥ß¥ó¥°ÆÃÏÀ

¥Í¥Ã¥È¥ï¡¼¥¯¥×¥í¥°¥é¥ß¥ó¥°ÆÃÏÀ 6 : JavaScript 2 : Web Web HTTPS : Web : Web, Internet Week 1 / 23 2 / 23 Web Web : HTTP: ( ) TCP: IP: ( ) Web 3 / 23 Basic (base64 ) ( ) Digest md5 Basic (nonce) hidden

More information

TFTP serverの実装

TFTP serverの実装 TFTP サーバーの実装 デジタルビジョンソリューション 佐藤史明 1 1 プレゼンのテーマ組み込みソフトのファイル転送を容易に 2 3 4 5 基礎知識 TFTP とは 実践 1 実際に作ってみよう 実践 2 組み込みソフトでの実装案 最後におさらい 2 プレゼンのテーマ 組み込みソフトのファイル転送を容易に テーマ選択の理由 現在従事しているプロジェクトで お客様からファームウェアなどのファイル転送を独自方式からTFTPに変更したいと要望があった

More information

ローカル ポリシーでの FIPS の有効化

ローカル ポリシーでの FIPS の有効化 ローカル ポリシーでの FIPS の有効化 FIPS NGE および AnyConnect について, 1 ページ AnyConnect コア VPN クライアントのための FIPS の設定, 5 ページ ネットワーク アクセス マネージャのための FIPS の設定, 6 ページ FIPS NGE および AnyConnect について AnyConnect には Cisco Common Cryptographic

More information

暗号方式委員会報告(CRYPTRECシンポジウム2012)

暗号方式委員会報告(CRYPTRECシンポジウム2012) 暗号方式委員会活動報告 安全性 実装性能評価リスト入りまでの基本的な流れ 事務局選出暗号 公募暗号技術 現リスト掲載暗号 次期リスト 電子政府推奨暗号リスト 推奨候補暗号リスト 運用監視暗号リスト 現リストのカテゴリ 技術分類公開鍵暗号共通鍵暗号その他 署名守秘鍵共有 64ビットブロック暗号 128 ビットブロック暗号 ストリーム暗号 ハッシュ関数 擬似乱数生成系 現リスト : 公開鍵暗号 技術分類

More information

正誤表(FPT0417)

正誤表(FPT0417) 正誤表 よくわかるマスター CompTIA Security+ 問題集試験番号 :SY0-101 対応 FPT0417 改版時期 奥付日付 2004 年 11 月 23 日 2007 年 09 月 03 日 2008 年 08 月 11 日 版数第 1 版 修正箇所 P 30 問題 89 c. 信頼性 c. 冗長性 P 64 問題 89 c 5 行目 ユーザの信頼性を確保することができます そのため

More information

運用ガイドラインWG活動報告

運用ガイドラインWG活動報告 1 運用ガイドライン WG 活動報告 主査菊池浩明 明治大学 2 背景 1: スノーデン事件とフォワードセキュリティ Edward Joseph Snowden 元米中央情報局 CIA 職員 米国家安全保障局 NSA へ出向していた 2013 年 6 月 13 日 香港英文紙に 米国政府が世界中の数万の標的を対象に電話記録やインターネット利用を極秘裏に監視していたことを暴露 Perfect Forward

More information

楕円曲線暗号の整備動向 +楕円暗号の実装状況

楕円曲線暗号の整備動向  +楕円暗号の実装状況 楕円曲線暗号の整備動向 + 楕円暗号の実装状況 2011 年 2 23 筑波 学 岡晃 2011/2/23 JNSA PKI 相互運用 WG 1 IPA 情報セキュリティ技術動向調査 TG ( タスク グループ ) 広範な情報セキュリティ分野において 継続的に かつ 質の い技術情報を収集し続けるため 半期毎に発表会形式の会合を開催し 討議をふまえて調査報告書を作成します http://www.ipa.go.jp/security/outline/comm

More information

ビットコイン (ブロックチェーン)

ビットコイン (ブロックチェーン) 暗号化 セカンドライフファクトリーわいわいサロン ( いつまでも勉強しよう!) 208 年 4 月 15 日 暗号化の利用 暗号化とは何か? 暗号化とは何か? https://www.jp.websecurity.symantec.com/welcome/pdf/wp_encryption_history.pdf 暗号化とは何か? 暗号化とは何か? インターネット上で使用される暗号化 (SSL)-01

More information

山添.pptx

山添.pptx アドホックネットワークにおけるセキュリティについての考察 ユビキタスネットワークシステム研究室 N11 101 山添優紀 2015.2.12 All Rights Reserved, Copyright 2013 Osaka Institute of Technology 背景 l アドホックネットワーク 無線基地局を必要とせず端末のみで構築できる無線ネットワーク 直接電波が届かない端末間も他の端末がデータを中継することで

More information

TLS _final

TLS _final TLS 1.3 IoT 2018/12/06, kojo@wolfssl.com wolfssl Japan GK 1 woflssl 2 3 : 200 E H : 200 I N Q : 2 / MSJ Q : 20. : 2.. # I N TC L. 00 0 L P : 2 T T 4 5 6 wolfssl Japan 7 108-6028 2-15-1 A 28F 050-3698-1916

More information

通信プロトコルの認証技術

通信プロトコルの認証技術 PKI IPsec/SSL IETF (http://www.netcocoon.com) 2004.12.9 IPsec ESP,AH,IPComp DOI:SA IKE SA ISAKMP IKE ESP IKE AH DOI Oakley ISAKMP IPComp SKEME IPsec IPv4TCP + IPv6TCP + IPv4 AH TCP + IPv6 AH + TCP IPv4

More information

SSL/TLS暗号設定ガイドライン

SSL/TLS暗号設定ガイドライン SSL/TLS 暗号設定 ガイドライン ~ 安全なウェブサイトのために ( 暗号設定対策編 )~ Ver. 2.0 作成 発行 本書は 以下の URL からもダウンロードできます SSL/TLS 暗号設定ガイドライン (IPA) https://www.ipa.go.jp/security/vuln/ssl_crypt_config.html (CRYPTREC) http://www.cryptrec.go.jp/

More information

セキュリティエリアの紹介

セキュリティエリアの紹介 1 IETF88th Technical Plenary IETF88 SECURITY AREA SATORU KANNO, NTT SOFTWARE DECEMBER 20, 2013 自己紹介 2 名前 菅野哲 ( かんのさとる ) 所属 NTT ソフトウェア その他の所属 IPA( 非常勤研究員 ) ISOC Japan Chapter(Program Committee) MIT-KIT

More information

cpvp_EAP-TTLS_ProVerif

cpvp_EAP-TTLS_ProVerif EAP-TTLS の ProVerif による評価結果 国立研究開発法人情報通信研究機構 1. 基本情報 名前 Extensible Authentication Protocol Tunneled Transport Layer Security Authenticated Protocol Version 0 (EAP-TTLSv0) 機能 EAP において TLS を用いて使用する暗号アルゴリズムのネゴシエーションとサー

More information

全てのパートナー様に該当する可能性のある 重要なお知らせです 2015 年 8 月 28 日 パートナー各位 合同会社シマンテック ウェブサイトセキュリティ SSL サーバ証明書における階層構造オプションの追加 および DNS Certification Authority Authorizatio

全てのパートナー様に該当する可能性のある 重要なお知らせです 2015 年 8 月 28 日 パートナー各位 合同会社シマンテック ウェブサイトセキュリティ SSL サーバ証明書における階層構造オプションの追加 および DNS Certification Authority Authorizatio 全てのパートナー様に該当する可能性のある 重要なお知らせです 2015 年 8 月 28 日 パートナー各位 合同会社シマンテック ウェブサイトセキュリティ SSL サーバ証明書における階層構造オプションの追加 および DNS Certification Authority Authorization(CAA) 対応について 平素より弊社製品の販売支援をいただき 誠にありがとうございます このたび弊社では

More information

Microsoft PowerPoint ppt

Microsoft PowerPoint ppt 情報セキュリティ第 06 回 大久保誠也 静岡県立大学経営情報学部 はじめに はじめに いままでの復習 RS 暗号の特徴 一方向関数とハッシュ値 演習 : ハッシュ値 2/34 復習 : 盗聴 lice からデータが来た 前回までの復習 送信 lice 盗聴 送信 :> で送信した情報は 基本的に盗聴し放題! 3/34 覗き見してやろう Eve 重要な情報は送らない or 暗号化 4/34 復習 :

More information

橡sirahasi.PDF

橡sirahasi.PDF Internet Week 2000 T5 IPsec VPN 2000/12/18 1 Virtual Private Network 2 IPsec 3 IPsec VPN 4 IPsec VPN 2 1 Virtual Private Network 3 Ethernet, WAN PPTP(PPP) IPSec SSL/TLS SOCKS V5 SSH, SSL-Telnet, PET PGP,

More information

AirStationPro初期設定

AirStationPro初期設定 AirStationPro 初期設定 AirStationPro の検索 1. エアステーション設定ツール Ver.2 を立ち上げて 次へ をクリックする 注 ) エアステーション設定ツール Ver.2 は 製品に付属している CD からインストールするか http://buffalo.jp/do wnload/driver/lan/ai rnavilite.html にあるエアナビゲータライト Ver.12.71

More information

Microsoft Word - r0703.doc

Microsoft Word - r0703.doc 新開発のパケット暗号処理方式により 暗号通信を高速化世界最速の業界標準 (IPsec) 対応暗号通信 (VP) 装置を開発 ( 開発 o.0703) 007 年 月 5 日三菱電機株式会社 三菱電機株式会社 ( 執行役社長 : 下村節宏 ) は パケット 暗号通信の業界標準規格 IPsecv に準拠して あらゆるサイズのパケットを 0Gbit イーサネット 3 の設計上の最大転送速度 ( ワイヤスピード

More information

証明書(Certificates)

証明書(Certificates) 証明書 Certificates デジタル証明書は 認証に使用されるデジタル ID を提供します 証明書は SSL セキュア ソケット レイヤ 接続 TLS Transport Layer Security 接続 および DTLS データグラム TLS 接続 HTTPS や LDAPS など に使用されます 次のトピックでは 証明書の作成と管 理の方法について説明します 証明書について 1 ページ

More information

IPSEC(Si-RG)

IPSEC(Si-RG) 技術情報 :Si-R/Si-R brin シリーズ設定例 (NTT 東日本 / NTT 西日本フレッツ光ネクスト ) フレッツ VPN プライオで拠点間を接続する設定例です フレッツ VPN プライオを利用して 拠点間を VPN( ) 接続します IPv4 パケットを IPv4 ヘッダでカプセリング (IPv4 over IPv4 IPsec tunnel) Si-R でトンネリングすることで以下の構成が可能になります

More information

DNSSECの基礎概要

DNSSECの基礎概要 DNSSEC の基礎概要 2012 年 11 月 21 日 Internet Week 2012 DNSSEC チュートリアル株式会社日本レジストリサービス (JPRS) 舩戸正和 Copyright 2012 株式会社日本レジストリサービス 1 本チュートリアルの内容 DNSSECの導入状況 DNSキャッシュへの毒入れと対策 DNSSECのしくみ 鍵と信頼の連鎖 DNSSECのリソースレコード(RR)

More information

スライド 1

スライド 1 ed25519 のすすめ Kazunori Fujiwara, JPRS fujiwara@jprs.co.jp 2018/6/27 まとめと URL など ED25519 は 3072 ビット RSA と同程度の暗号強度であるにもかかわらず 公開鍵 署名サイズが非常に小さいため DNSSEC のパケットサイズ問題を改善できる ( フラグメントなし運用しやすい ) ED25519 の実装が進んできているので

More information

サブスクライバー / 署名者 Subscriber 側 ( アリス ) の要件 セキュアな署名 なりすましをいかに防ぐか 署名に使用する私有鍵をいかに保護私有鍵をいかに保護するか?? セキュアなハードウェアトークンなどが有効 セキュアな装置のセキュリティ基準 欧州の電子署名では SSCD (Secu

サブスクライバー / 署名者 Subscriber 側 ( アリス ) の要件 セキュアな署名 なりすましをいかに防ぐか 署名に使用する私有鍵をいかに保護私有鍵をいかに保護するか?? セキュアなハードウェアトークンなどが有効 セキュアな装置のセキュリティ基準 欧州の電子署名では SSCD (Secu サブスクライバー / 署名者 1 サブスクライバー / 署名者 Subscriber 側 ( アリス ) の要件 セキュアな署名 なりすましをいかに防ぐか 署名に使用する私有鍵をいかに保護私有鍵をいかに保護するか?? セキュアなハードウェアトークンなどが有効 セキュアな装置のセキュリティ基準 欧州の電子署名では SSCD (Secure signature creation device ) としてその要件を定義

More information

目次 1. 既存ワンタイムパスワード方式の課題 2.IOTP の特徴 3.IOTP の仕様 4. 安全性 可用性評価 5. 実施例 6. 知的所有権情報 7. まとめ 1 All Rights Reserved,Copyright 日本ユニシス株式会社

目次 1. 既存ワンタイムパスワード方式の課題 2.IOTP の特徴 3.IOTP の仕様 4. 安全性 可用性評価 5. 実施例 6. 知的所有権情報 7. まとめ 1 All Rights Reserved,Copyright 日本ユニシス株式会社 CRYPTREC 提出資料 8 説明会発表資料 無限ワンタイムパスワード認証方式 Infinite OneTime Password:IOTP 平成 22 年 2 月 1 日 日本ユニシス株式会社 八津川直伸 目次 1. 既存ワンタイムパスワード方式の課題 2.IOTP の特徴 3.IOTP の仕様 4. 安全性 可用性評価 5. 実施例 6. 知的所有権情報 7. まとめ 1 All Rights

More information

PowerPoint プレゼンテーション

PowerPoint プレゼンテーション 1. 認証 (authentication) とは (1) 本物 本人であることを確認すること 送られた注文書は本物か パソコンやサーバへログインしたのは本人か メールを送信したのは本人か など (2) 認証の方法 1 本物認証 : 電子署名 ( ディジタル署名 ) 2ユーザ認証 : ユーザID+パスワード バイオメトリクス ( 生体 ) 認証 1 1 2. 電子署名 ( ディジタル署名 ) (1)

More information

シナリオ:サイトツーサイト VPN の設定

シナリオ:サイトツーサイト  VPN の設定 CHAPTER 4 シナリオ : サイトツーサイト VPN の設定 この章では セキュリティアプライアンスを使用してサイトツーサイト VPN を作成する方法について説明します セキュリティアプライアンスが提供するサイトツーサイト VPN 機能を使用すると ネットワークセキュリティを維持しながら 低コストな公衆インターネット接続で ビジネスネットワークを世界中のビジネスパートナー およびリモートオフィスに拡張できます

More information

type nonce. type host. consts const request_id: bitstring [data]. const response_id: bitstring [data]. const start_ttls: bitstring [data]. const succe

type nonce. type host. consts const request_id: bitstring [data]. const response_id: bitstring [data]. const start_ttls: bitstring [data]. const succe 暗号プロトコル評価結果 独立行政法人情報通信研究機構 1. プロトコル名 :EAP-TTLS 2. 関連する標準 IETF:RFC5281 (http://www.ietf.org/rfc/rfc5281.txt) 3. 使用したツール :Proverif 4. 評価の概要 :Proverif による評価では 攻撃は発見されなかった 5.ProVerif による評価 以下では ロール S(Access

More information

VPN 接続の設定

VPN 接続の設定 VPN 接続の設定 AnyConnect 設定の概要, 1 ページ AnyConnect 接続エントリについて, 2 ページ ハイパーリンクによる接続エントリの追加, 2 ページ 手動での接続エントリの追加, 3 ページ ユーザ証明書について, 4 ページ ハイパーリンクによる証明書のインポート, 5 ページ 手動での証明書のインポート, 5 ページ セキュアゲートウェイから提供される証明書のインポート,

More information

Juniper Networks Corporate PowerPoint Template

Juniper Networks Corporate PowerPoint Template Juniper SRX 日本語マニュアル 41. SSL Forward Proxy の CLI 設定 はじめに SRX340 における SSL Forward Proxy の CLI 設定ついて説明します 手順内容は SRX340 JUNOS 15.1X49-D140 にて確認を実施しております SSL Proxy 機能については SRX340 以上の機種にてサポートされています 2018 年 8

More information

Microsoft PowerPoint - 2k_SSL Value for Customers.pptx

Microsoft PowerPoint - 2k_SSL Value for Customers.pptx F5ネットワークスジャパン 2010 年 10 月 SSL 公 開 鍵 長 の2048ビット 移 行 と BIG-IPによるSSLオフロードの に ド 価 値 について セキュリティガイダンス およびその 影 響 3 暗 号 アルゴリズムにおける2010 年 問 題 2010 年 問 題 現 在 使 われている 暗 号 アルゴリズムが 将 来 的 に 使 用 できなくなることに 伴 って 発 生 する

More information

PKI(Public Key Infrastructure: 公開鍵暗号基盤 ) の活用 1 認証局ソフトウェアで証明書を発行する認証局ソフトウェア (Easy Cert) で認証局を構築する手順を示す この Easy Cert は名古屋工業大学電気情報工学科の岩田研究室で開発された暗号ライブラリを

PKI(Public Key Infrastructure: 公開鍵暗号基盤 ) の活用 1 認証局ソフトウェアで証明書を発行する認証局ソフトウェア (Easy Cert) で認証局を構築する手順を示す この Easy Cert は名古屋工業大学電気情報工学科の岩田研究室で開発された暗号ライブラリを PKI(Public Key Infrastructure: 公開鍵暗号基盤 ) の活用 1 認証局ソフトウェアで証明書を発行する認証局ソフトウェア (Easy Cert) で認証局を構築する手順を示す この Easy Cert は名古屋工業大学電気情報工学科の岩田研究室で開発された暗号ライブラリをベースにして開発された認証局ソフトウェアである 証明書と失効リストの発行を主眼にしており 登録局やリポジトリの要素は省略されている

More information

2. 機能 ( 標準サポートプロトコル ) SECURITY for Biz 対応スマートフォンでは標準で対応している VPN プロトコルがあります 本章では NTT ドコモで動作確認を実施している PPTP L2TP/IPSec IPSec Xauth について記載します PPTP(Point-t

2. 機能 ( 標準サポートプロトコル ) SECURITY for Biz 対応スマートフォンでは標準で対応している VPN プロトコルがあります 本章では NTT ドコモで動作確認を実施している PPTP L2TP/IPSec IPSec Xauth について記載します PPTP(Point-t VPN 1. 概要 VPN とは Virtual Private Network の略称であり インターネット等を介して端末と企業等のプライベートネットワーク ( 以下 社内ネットワーク とします ) を接続する技術のことです トンネリングや暗号化の技術により仮想的な専用線を実現し セキュアな社内ネットワークへの接続を確立します NTT ドコモの提供する SECURITY for Biz 対応スマートフォン(

More information

Anonymous IPsec with Plug and Play

Anonymous IPsec with Plug and Play 本資料について 本資料は下記論文を基にして作成されたものです 文書の内容の正確さは保証できないため 正確な知識を求める方は原文を参照してください 著者 :Kazuomi Oishi,Haruyuki Kitawaki 論文名 :Anonymous IPsec with Plug and Play: 出展 :IC2004 a prototype of IPsec with IKE using IPv6

More information

インターネットVPN_IPoE_IPv6_fqdn

インターネットVPN_IPoE_IPv6_fqdn 技術情報 :Si-R/Si-R brin シリーズ設定例 (NTT 東日本 / NTT 西日本フレッツ光ネクスト ) IPv6 IPoE 方式 ( ひかり電話契約なし ) で拠点間を接続する設定例です フレッツ光ネクストのフレッツ v6 オプションを利用して 拠点間を VPN( ) 接続します IPv6 IPoE 方式 ( ひかり電話契約なし ) の場合 /64 のプレフィックスをひとつ配布されますが

More information

技術情報:Si-R/Si-R brinシリーズ設定例 「Oracle Cloud Infrastructure Classic」との接続

技術情報:Si-R/Si-R brinシリーズ設定例 「Oracle Cloud Infrastructure Classic」との接続 技術情報 :Si-R/Si-R brin シリーズ設定例 Oracle Cloud Infrastructure Classic との接続 Si-R G シリーズで Oracle Cloud Infrastructure Classic に IPsec 接続する場合の設定例です 本設定例は 弊社で独自に接続試験 (2018 年 7 月 ) を行った結果を元に作成しております 今後 仕様変更などの可能性もありますので

More information

Microsoft PowerPoint SCOPE-presen

Microsoft PowerPoint SCOPE-presen H19-21 SCOPE 若手 ICT 研究者育成型研究開発 楕円曲線暗号を用いた 匿名認証基盤の研究開発 岡山大学大学院自然科学研究科 中西 野上 透 保之 1 研究の背景 ユビキタス社会では ユーザ認証を通じ ユーザ認証を通じユーザの様々な履歴がサーバに蓄積 ID:Alice Pass: ***** ユーザ ID:Alice インターネットサーバ 様々な機器からの利用 様々な場所からの利用 Pass:

More information

SFTPサーバー作成ガイド

SFTPサーバー作成ガイド Version 2018 - 第 1 版 Titan FTP Server SFTP サーバー作成ガイド 作成 : 株式会社エーディーディー 目次 インストール...1 アクティベーション...2 ローカルドメイン設定作業...3 SFTP サーバー作成手順...5 ユーザー作成...8 クライアント用のホストキーの出力...9 インストール Titan FTP を Windows にインストールします

More information

RADIUS 無効な認証者およびメッセージ認証者のトラブルシューティング ガイド

RADIUS 無効な認証者およびメッセージ認証者のトラブルシューティング ガイド RADIUS 無効な認証者およびメッセージ認証者のトラブルシューティングガイド 目次 概要オーセンティケータヘッダ応答の認証いつ検証エラーを待つ必要がありますか パスワード隠れること再送信アカウンティングメッセージオーセンティケータアトリビュートメッセージオーセンティケータはいつ使用する必要がありますか いつ検証エラーを待つ必要がありますか メッセージオーセンティケータアトリビュートを検証して下さい関連情報

More information

Clearswift PPT Template

Clearswift PPT Template Clearswift SECURE Email Gateway メール暗号化機能のご紹介 www.clearswift.com メールの暗号化が必要な理由 移動中のデータを保護するため 情報漏洩を防ぐため 社会的信用の毀損 ブランド力の低下から企業価値を保護するため 法規 各業界のレギュレーション遵守のため www.clearswift.com 2 Clearswift SEG がサポートする暗号化の種類

More information

SmartGS-ReleaseNote-V132

SmartGS-ReleaseNote-V132 お客様各位 セイコーソリューションズ株式会社 SmartGS Version 1.3.2 リリースノート 目次 Version1.3.2 (2017 年 7 月 )... 4 1 仕様変更... 4 1.1 対応ブラウザに Internet Explorer を追加... 4 Version1.3.1 (2017 年 1 月 )... 5 1 仕様変更... 5 1.1 SSL サーバ証明書の署名アルゴリズムを変更...

More information

UID S307-NDEF

UID S307-NDEF [White Paper] Ubiquitous ID Center Specification DRAFT 2012-05-15 NFC ucode タグのメモリフォーマット規定 Standard of memory format of NFC ucode tag Number: Title: NFC ucode タグのメモリフォーマット規定 Standard of memory format of

More information

Internet Initiative Japan Inc. プロトコルの脆弱性 ( 株 ) インターネットイニシアティブ 永尾禎啓 Copyright 2004, Internet Initiative Japan Inc.

Internet Initiative Japan Inc. プロトコルの脆弱性 ( 株 ) インターネットイニシアティブ 永尾禎啓 Copyright 2004, Internet Initiative Japan Inc. プロトコルの脆弱性 ( 株 ) インターネットイニシアティブ 永尾禎啓 nagao@iij.ad.jp Copyright 2004, TCP/IP プロトコルスタックの脆弱性 プロトコルの仕様から見た脆弱性の分類 1. 仕様は正しいが 実装上のバグ 2. 仕様の曖昧さに起因! 実装によっては脆弱性が存在 3. 仕様自体のバグ 4. バグではないが仕様上不可避な問題 プロトコルの脆弱性 とは " プロトコルの仕様に起因する脆弱性

More information

PowerPoint Presentation

PowerPoint Presentation 2009 年 2 月 18 日 CRYPTREC ワークショップ 暗号利用モードの最新動向 富士通研究所下山武司 暗号利用モードの経緯 1 ブロック暗号 (ECB モード ) 平文 Enc 暗号文 鍵 同じ平文に対しては同じ暗号文 乱数列と識別可能 ( 右に例示 ) 原画 ECB モード暗号化 出典 http://en.wikipedia.org/wiki/block_cipher_modes_of_operation

More information

HULFT の通信をよりセキュアに HULFT と SSH Tectia を組み合わせたセキュアで強力なファイル転送 Compatibility Note 2008 年 9 月 株式会社セゾン情報システムズの企業内 企業間通信ミドルウェアである HULFT は ファイル転送のアプリケーションとして

HULFT の通信をよりセキュアに HULFT と SSH Tectia を組み合わせたセキュアで強力なファイル転送 Compatibility Note 2008 年 9 月 株式会社セゾン情報システムズの企業内 企業間通信ミドルウェアである HULFT は ファイル転送のアプリケーションとして HULFT の通信をよりセキュアに HULFT と SSH Tectia を組み合わせたセキュアで強力なファイル転送 Compatibility Note 2008 年 9 月 株式会社セゾン情報システムズの企業内 企業間通信ミドルウェアである HULFT は ファイル転送のアプリケーションとして 主に流通業 製造業で大きなシェアを誇るパッケージソフトウェアです SSH Tectia ソリューションを

More information

cpvp_PKM_ProVerif

cpvp_PKM_ProVerif PKM の ProVerif による評価結果 国立研究開発法人情報通信研究機構 1. 基本情報 名前 PKM (Privacy and Key Management Protocol) 機能 Wimax 通信における端末 (SS/MS) と基地局 (BS) 間の認証 鍵交換プロトコル 関連する標準 IEEE Std 802.16e-2005 (http://standards.ieee.org/getieee802/download/802.16e-2005.pdf)

More information

SSL/TLSサーバ構築ガイドライン

SSL/TLSサーバ構築ガイドライン SSL/TLS 暗号設定暗号スイートの設定例 平成 27 年 8 月 独立行政法人情報処理推進機構 国立研究開発法人情報通信研究機構 目次 1. Windows での設定例... 2 2. OpenSSL 系での設定例... 3 2.1. Apache, lighttpd, nginx の場合... 3 2.2. OpenSSL 系での暗号スイートの設定例... 4 SSL/TLS 暗号設定暗号スイートの設定例

More information

1 暗号化通信におけるリスク ~ SSH に潜む落とし穴 ~ 暗号化すれば安全ですか? 目次 1. はじめに SSH とは SSH に潜む落とし穴 SSH での効果的な対策 最後に... 13

1 暗号化通信におけるリスク ~ SSH に潜む落とし穴 ~ 暗号化すれば安全ですか? 目次 1. はじめに SSH とは SSH に潜む落とし穴 SSH での効果的な対策 最後に... 13 暗号化通信におけるリスク ~ SSH に潜む落とし穴 ~ 暗号化すれば安全ですか? 2015 年 09 月 1 暗号化通信におけるリスク ~ SSH に潜む落とし穴 ~ 暗号化すれば安全ですか? 目次 1. はじめに... 2 2. SSH とは... 3 3. SSH に潜む落とし穴... 6 4. SSH での効果的な対策... 10 5. 最後に... 13 2 暗号化通信におけるリスク ~

More information

PowerPoint プレゼンテーション

PowerPoint プレゼンテーション 1 IETF88th Technical Plenary PKI DAY 2014 IETF での TLS 関連の標準化動向 SATORU KANNO MARCH 13, 2014 自己紹介 2 名前 菅野哲 ( かんのさとる ) 所属 NTT ソフトウェア株式会社 その他の所属 IPA( 非常勤研究員 ) ISOC Japan Chapter(Program Committee) MIT-KIT

More information

Windows PowerShell 用スクリプト形式編 改版履歴 版数 日付 内容 担当 V /4/1 初版 NII V /2/26 動作環境の変更に伴う修正 NII V /8/21 タイムスタンプ利用手順の追加 NII 目次 1. コード署名用証明

Windows PowerShell 用スクリプト形式編 改版履歴 版数 日付 内容 担当 V /4/1 初版 NII V /2/26 動作環境の変更に伴う修正 NII V /8/21 タイムスタンプ利用手順の追加 NII 目次 1. コード署名用証明 Windows PowerShell 用スクリプト形式編 改版履歴 版数 日付 内容 担当 V.1.0 2015/4/1 初版 NII V.0 2018/2/26 動作環境の変更に伴う修正 NII V.1 2018/8/21 タイムスタンプ利用手順の追加 NII 目次 1. コード署名用証明書の利用 1-1. 前提条件 1- PKCS#12 ファイルの作成 1-2-1. 事前準備 1-2- PKCS#12

More information

2. 機能 ( 標準サポートプロトコル ) NTT ドコモの Android スマートフォン / タブレットでは標準で対応している VPN プロトコルがあります 本章では 動作確認を実施している PPTP L2TP/IPSec IPSec Xauth について記載します PPTP(Point-to-

2. 機能 ( 標準サポートプロトコル ) NTT ドコモの Android スマートフォン / タブレットでは標準で対応している VPN プロトコルがあります 本章では 動作確認を実施している PPTP L2TP/IPSec IPSec Xauth について記載します PPTP(Point-to- VPN 1. 概要 VPN とは Virtual Private Network の略称であり インターネット等を介して端末と企業等のプライベートネットワーク ( 以下 社内ネットワーク とします ) を接続する技術のことです トンネリングや暗号化の技術により仮想的な専用線を実現し セキュアな社内ネットワークへの接続を確立します NTT ドコモの提供する Android スマートフォン / タブレットにおいては

More information

無線 LAN セキュリティの基礎 2015 年 4 月 19 日セクタンラボ Copyright (C) 2015 SecTan Lab. All Rights Reserved.

無線 LAN セキュリティの基礎 2015 年 4 月 19 日セクタンラボ Copyright (C) 2015 SecTan Lab. All Rights Reserved. 無線 LAN セキュリティの基礎 2015 年 4 月 19 日セクタンラボ Copyright (C) 2015 SecTan Lab. All Rights Reserved. 1. 無線 LAN セキュリティの基礎 P 2 無線 LAN ネットワークに対する脅威 ネットワークセキュリティの視点で見ると, 無線 LAN の利用には, 大きく分けて 3 種類の脅威があります 1 通信の盗聴 無線通信

More information

自己紹介 名前 : 一ノ瀬太樹 所属 : HASH コンサルティング株式会社 OWASP Japan プロモーションチーム OWASP ZAP ユーザーグループ脆弱性診断研究会 ( 管理者その 3) Perl 入学式 ( サポーター ) HASH Consult

自己紹介 名前 : 一ノ瀬太樹 所属 : HASH コンサルティング株式会社 OWASP Japan プロモーションチーム OWASP ZAP ユーザーグループ脆弱性診断研究会 ( 管理者その 3) Perl 入学式 ( サポーター ) HASH Consult Affected 指定されているけど PoC が無いフレームワークで再現試験をした話 WASNight 2016 Summer = WASForum x OWASP Night 2016/8/16 一ノ瀬太樹 HASH Consulting Corp. 自己紹介 名前 : 一ノ瀬太樹 Twitter: @mahoyaya 所属 : HASH コンサルティング株式会社 OWASP Japan プロモーションチーム

More information

[ 証明書の申請から取得まで ] で受領したサーバ証明書を server.cer という名前で任意の場所に保存してください ( 本マニュアルではローカルディスクの work ディレクトリ [C:\work] に保存しています ) 中間 CA 証明書を準備します 次の URL にアク

[ 証明書の申請から取得まで ] で受領したサーバ証明書を server.cer という名前で任意の場所に保存してください ( 本マニュアルではローカルディスクの work ディレクトリ [C:\work] に保存しています ) 中間 CA 証明書を準備します 次の URL にアク IIS10.0 編 改版履歴 版数 日付 内容 担当 V.1.0 2018/2/26 初版 NII V.1.1 2018/3/26 CT 対応版の中間 CA 証明書について説明を追加 NII V.1.2 2018/7/9 ECDSA 対応版のルート証明書 中間 CA 証明書について説明を追加 NII 目次 1. IIS10.0 によるサーバ証明書の利用 1-1. 前提条件 1-2. 証明書のインストール

More information

DNSSEC の仕組みと現状 平成 22 年 11 月 DNSSEC ジャパン

DNSSEC の仕組みと現状 平成 22 年 11 月 DNSSEC ジャパン DNSSEC の仕組みと現状 平成 22 年 11 月 DNSSEC ジャパン アジェンダ 1. DNSとは 2. DNSの動作 3. DNSSECとは 4. DNSSECの動作 5. DNSSECの現状 6. 参考 URL 7. DNSSEC 関連 RFC 2 DNS とは DNS(Domain Name System) とは ホスト ( ドメイン ) 名を IP アドレスに IP アドレスをホスト

More information

暗号プロトコル評価結果 独立行政法人情報通信研究機構 1. プロトコル名 :PKM 2. 関連する標準 IEEE Std e 使用したツール :S

暗号プロトコル評価結果 独立行政法人情報通信研究機構 1. プロトコル名 :PKM 2. 関連する標準 IEEE Std e 使用したツール :S 暗号プロトコル評価結果 独立行政法人情報通信研究機構 1. プロトコル名 :PKM 2. 関連する標準 IEEE Std 802.16e-2005 http://standards.ieee.org/getieee802/download/802.16e-2005.pdf 3. 使用したツール :Scyther 4. 評価の概要 :Scyther による評価では weak agreement への攻撃の可能性が指摘されているが

More information

Microsoft PowerPoint - janog39.5_afterJanog39-suga

Microsoft PowerPoint - janog39.5_afterJanog39-suga JANOG 39.5 Interim meeting, April 14th, 2017 JANOG39 で話した後, 某業界のログインサイトに特化して再調査してみたら ( 表 ) 事前公開資料 セキュリティ本部セキュリティ情報統括室須賀祐治 2017-04-14 2017 Internet Initiative Japan Inc. 1 自己紹介 TLS を愛し TLS に愛された男 2017 Internet

More information

他の章は下記をクリックして PDF 一覧からお入り下さい IT ライブラリー (pdf 100 冊 ) 目次番号 270 番 Windows Server Enterprise 2008 R2 完全解説 ( 再入門 )

他の章は下記をクリックして PDF 一覧からお入り下さい IT ライブラリー (pdf 100 冊 )   目次番号 270 番 Windows Server Enterprise 2008 R2 完全解説 ( 再入門 ) IT ライブラリーより (pdf 100 冊 ) http://www.geocities.jp/ittaizen/itlib1/ BranchCache 機能紹介資料 他の章は下記をクリックして PDF 一覧からお入り下さい IT ライブラリー (pdf 100 冊 ) http://www.geocities.jp/ittaizen/itlib1/ 目次番号 270 番 Windows Server

More information

企業ネットワークにおける 認証基盤の構築に関する研究

企業ネットワークにおける 認証基盤の構築に関する研究 PKI Public Key Infrastructure PKI PKI PKI PKI PKI CA(Certificate Authority) CA CA CA root CA CA root CA PKI CRL Certificate Revocation List CRL CRL CRL PKI 1 CRL A 1 1 PKI PKI root CA CRL (1) PKI 2001

More information

はじめに はじめに 本書について本書はオールインワン認証アプライアンス NetAttest EPS と ELECOM 社製無線アクセスポイント WAB-M2133 の IEEE802.1X EAP-TLS/EAP-PEAP(MS-CHAP V2) 環境での接続について 設定例を示したものです 設定例

はじめに はじめに 本書について本書はオールインワン認証アプライアンス NetAttest EPS と ELECOM 社製無線アクセスポイント WAB-M2133 の IEEE802.1X EAP-TLS/EAP-PEAP(MS-CHAP V2) 環境での接続について 設定例を示したものです 設定例 認証連携設定例 連携機器 ELECOM WAB-M2133 Case IEEE802.1X EAP-TLS/EAP-PEAP(MS-CHAP V2) Rev1.0 株式会社ソリトンシステムズ はじめに はじめに 本書について本書はオールインワン認証アプライアンス NetAttest EPS と ELECOM 社製無線アクセスポイント WAB-M2133 の IEEE802.1X EAP-TLS/EAP-PEAP(MS-CHAP

More information

製品ラインアップ ハードウェア < 部品としてのご提供 > ーお客様でソフトエアの開発が必要ですー弊社で受託開発も可能です チャレンジ & レスポンス Web 構築に最適ドライバレスタイプ : epass1000nd チャレンジ & レスポンス方式 電子証明書の格納に両方対応可能汎用型タイプ : e

製品ラインアップ ハードウェア < 部品としてのご提供 > ーお客様でソフトエアの開発が必要ですー弊社で受託開発も可能です チャレンジ & レスポンス Web 構築に最適ドライバレスタイプ : epass1000nd チャレンジ & レスポンス方式 電子証明書の格納に両方対応可能汎用型タイプ : e PC& ソフトのセキュリティは epass におまかせ! PC 認証 USB トークン製品概要 epass シリーズ ビス株式会社 飛天ジャパン株式会社 2009/6/1 製品ラインアップ ハードウェア < 部品としてのご提供 > ーお客様でソフトエアの開発が必要ですー弊社で受託開発も可能です チャレンジ & レスポンス Web 構築に最適ドライバレスタイプ : epass1000nd チャレンジ

More information

ASF-01

ASF-01 暗号モジュール試験及び認証制度 (JCMVP) 承認されたセキュリティ機能に関する仕様 平成 26 年 4 月 1 日独立行政法人情報処理推進機構 ASF-01 A p p r o v e d S e c u r i t y F u n c t i o n s 目次 1. 目的... 1 2. 承認されたセキュリティ機能... 1 公開鍵... 1 共通鍵... 3 ハッシュ... 4 メッセージ認証...

More information

SOC Report

SOC Report Web ブラウザの SOCKS 実装状況について N T T コ ミ ュ ニ ケ ー シ ョ ン ズ株式会社 経営企画部 マネージドセキュリティサービス推進室 セ キ ュ リ テ ィ オ ペ レ ー シ ョ ン担当 2013 年 03 月 11 日 Ver. 1.0 1. 調査概要... 3 1.1. 調査概要... 3 2. SOCKS とは... 3 2.1. SOCKSとは... 3 2.2.

More information

目次 1. はじめに SSL 通信を使用する上での課題 SSL アクセラレーターによる解決 SSL アクセラレーターの導入例 SSL アクセラレーターの効果... 6 富士通の SSL アクセラレーター装置のラインナップ... 8

目次 1. はじめに SSL 通信を使用する上での課題 SSL アクセラレーターによる解決 SSL アクセラレーターの導入例 SSL アクセラレーターの効果... 6 富士通の SSL アクセラレーター装置のラインナップ... 8 IPCOM 目次 1. はじめに... 1 2.SSL 通信を使用する上での課題... 2 3.SSL アクセラレーターによる解決... 3 4.SSL アクセラレーターの導入例... 4 5.SSL アクセラレーターの効果... 6 富士通の SSL アクセラレーター装置のラインナップ... 8 1. はじめに SSL は インターネット上で最も良く使われている暗号技術です SSL は 通信内容を暗号化して盗聴を防ぐ機能のほかに

More information

<834B A982E782CC97768C8F928A8F6F2E786C73>

<834B A982E782CC97768C8F928A8F6F2E786C73> SA は 一つ以上のプロポーザルが入った SA ネゴシエーションペイロードである イニシエータは ネゴシエーションにあたって複数の提案を行なってもよい : レスポンダは一つに対してだけリプライしなければならない (ISAKMP ヘッダの後に '*' がついて表わされる ) メッセージ暗号化は ISAKMP ヘッダの直後から始まらなければならない 通信を保護する場合 ISAKMP ヘッダに続くすべてのペイロードは暗号化されなければならない

More information

目次 1 概要 モジュール概要 暗号モジュールの仕様 暗号境界 物理的暗号境界 論理的暗号境界 動作モードとアルゴリズム ポートとインタフェース 暗号モジュール

目次 1 概要 モジュール概要 暗号モジュールの仕様 暗号境界 物理的暗号境界 論理的暗号境界 動作モードとアルゴリズム ポートとインタフェース 暗号モジュール SecureWare/ 開発キット Ver5.1 セキュリティポリシ 2016 年 11 月 15 日 Version 1.97 日本電気株式会社 目次 1 概要... 1 2 モジュール概要... 1 3 暗号モジュールの仕様... 1 3.1 暗号境界... 1 3.1.1 物理的暗号境界... 1 3.1.2 論理的暗号境界... 4 3.2 動作モードとアルゴリズム... 4 3.3 ポートとインタフェース...

More information

untitled

untitled API API Part 1 10API 25 10API Part2 Copyright (c) 2004 NPO Page 2 Copyright (C) 2004 NPO JNSA 1 API API Wassenaar API Copyright (c) 2004 NPO Page 4 Copyright (C) 2004 NPO JNSA 2 56 512512 112 IC 1 I II

More information

■POP3の廃止について

■POP3の廃止について 最終更新日 :2017.8.28 メール受信方式の変更手順書 (Outlook 版 ) 情報連携統括本部 POP3 の廃止について メール受信方式の一つである POP3 形式はセキュリティ上の問題があるため 2011 年度夏に行いました キャンパス情報基幹システム の更新の際にお知らせいたしました通り 2017 年度夏の更新を持ちまして廃止いたします これにより 更新後は POP3 によるメールの受信はできなくなり

More information

大阪大学キャンパスメールサービスの利用開始方法

大阪大学キャンパスメールサービスの利用開始方法 大阪大学キャンパスメールサービスの利用開始方法 大阪大学キャンパスメールを用いた 基礎工学研究科機能創成専攻 のメールサービスがスタートしますので 下記のような切り替え作業をお願いします キャンパスメールサーバの準備ができれば (13 時頃予定 ) メールは新サーバにのみ届きますので できるだけ早い時期に切り替え作業を行っていただく必要があります 利用開始手順の概要 1. 旧サーバでの最後のメール受信

More information

SecureWare/ 開発キット Ver5.0 セキュリティポリシ 2012 年 5 月 24 日 Version 1.96 日本電気株式会社

SecureWare/ 開発キット Ver5.0 セキュリティポリシ 2012 年 5 月 24 日 Version 1.96 日本電気株式会社 SecureWare/ 開発キット Ver5.0 セキュリティポリシ 2012 年 5 月 24 日 Version 1.96 日本電気株式会社 目次 1 概要... 1 2 モジュール概要... 1 3 暗号モジュールの仕様... 1 3.1 暗号境界... 1 3.1.1 物理的暗号境界... 1 3.1.2 論理的暗号境界... 4 3.2 動作モードとアルゴリズム... 4 3.3 ポートとインタフェース...

More information

脆弱性 (CTX230612) の対応方法 対応方法設定手順 GUI での設定方法 realserver に対するクライアント証明書の認証解除 CipherSuite の DHE を無効化 CLI での設定方法 realserver に対するクライアント証明書の認証解除 CipherSuite の

脆弱性 (CTX230612) の対応方法 対応方法設定手順 GUI での設定方法 realserver に対するクライアント証明書の認証解除 CipherSuite の DHE を無効化 CLI での設定方法 realserver に対するクライアント証明書の認証解除 CipherSuite の 脆弱性 (CTX230612) の対応方法 対応方法設定手順 GUI での設定方法 realserver に対するクライアント証明書の認証解除 CipherSuite の DHE を無効化 CLI での設定方法 realserver に対するクライアント証明書の認証解除 CipherSuite の DHE を無効化 対応方法 NetSCaler と realserver 間の認証にクライアント証明書を利用している場合

More information

実務に役立つサーバー運用管理の基礎 CompTIA Server+ テキスト SK0-004 対応

実務に役立つサーバー運用管理の基礎 CompTIA Server+ テキスト SK0-004 対応 実務に役立つサーバー運用管理の基礎 CompTIA Server+ テキスト SK0-004 対応 本書 前提知識 1 1-1 1-1-1 1-1-2 役割 1-1-3 形状 筐体 1-2 1-2-1 CPU 1-2-2 1-2-3 1-2-4 拡張 拡張 1-2-5 BIOS/UEFI 1-2-6 電源 1-2-7 2 2-1 2-1-1 通信 2-1-2 層 2-1-3 層 層 2-1-4 層

More information

パスワード暗号化の設定

パスワード暗号化の設定 この章では Cisco NX-OS デバイスにパスワード暗号化を設定する手順について説明します この章は 次の内容で構成されています AES パスワード暗号化およびマスター暗号キーについて, 1 ページ パスワード暗号化のライセンス要件, 2 ページ パスワード暗号化の注意事項と制約事項, 2 ページ パスワード暗号化のデフォルト設定, 2 ページ, 3 ページ の確認, 6 ページ 例, 6 ページ

More information

DNSOPS.JP BoF nginxを利 した DNS over TLS 対応フルリゾルバの作り ( 株 ) ハートビーツ滝澤隆史

DNSOPS.JP BoF nginxを利 した DNS over TLS 対応フルリゾルバの作り ( 株 ) ハートビーツ滝澤隆史 DNSOPS.JP BoF nginxを利 した DNS over TLS 対応フルリゾルバの作り ( 株 ) ハートビーツ滝澤隆史 2 私は誰 名 : 滝澤隆史 @ttkzw 所属 : 株式会社ハートビーツ ウェブ系のサーバの構築 運 や 24 時間 365 の有 監視をやっている会社 いわゆる MSP( マネージドサービスプロバイダ ) 本 Unbound ユーザー会 Unbound/NSD の

More information

IPSEC(Si-RGX)

IPSEC(Si-RGX) 技術情報 :Si-R/Si-R brin シリーズ設定例 (NTT 東日本 / NTT 西日本フレッツ光ネクスト ) フレッツ VPN プライオで拠点間を接続する設定例です フレッツ VPN プライオを利用して 拠点間を VPN( ) 接続します IPv4 パケットを IPv4 ヘッダでカプセリング (IPv4 over IPv4 IPsec tunnel) Si-R でトンネリングすることで以下の構成が可能になります

More information

(Microsoft PowerPoint - 20150320CRYPTREC\203V\203\223\203|\203W\203E\203\200.v4.handsout)

(Microsoft PowerPoint - 20150320CRYPTREC\203V\203\223\203|\203W\203E\203\200.v4.handsout) CRYPTREC Symposium 2015, March 20 th, 2015, Tokyo, Japan ISPから 見 た 暗 号 技 術 ( 仮 題 ) 株 式 会 社 インターネットイニシアティブ セキュリティ 情 報 統 括 室 須 賀 祐 治 2015-03-20 1 CRYPTREC Symposium 2015, March 20 th, 2015, Tokyo, Japan

More information

MC-04 暗号アルゴリズム移行における オペレータ認証基盤の運用ガイドライン 平成 23 年 12 月 26 日 1.0 版 一般社団法人電波産業会 高度無線通信研究委員会 モバイルコマース部会

MC-04 暗号アルゴリズム移行における オペレータ認証基盤の運用ガイドライン 平成 23 年 12 月 26 日 1.0 版 一般社団法人電波産業会 高度無線通信研究委員会 モバイルコマース部会 MC-04 暗号アルゴリズム移行における オペレータ認証基盤の運用ガイドライン 平成 23 年 12 月 26 日 1.0 版 一般社団法人電波産業会 高度無線通信研究委員会 モバイルコマース部会 暗号アルゴリズム移行における オペレータ認証基盤の運用ガイドライン 目次 1. はじめに...1 1.1. 検討の背景と目的...1 1.1.1. 2010 年問題の調査結果...1 1.2. 検討のスコープ...3

More information