![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
[[FrontPage]] *概要 [#vf109c7f] -手紙の内容を誰にも見られたくない。でもこれを見知らぬ誰かに送りたい。これを極めた形がセキュリティ --手紙を想定すると結構いろいろうまく行く -セキュリティとかプライバシーって霊なんで。普段ボンヤリとしか見えないんだけど、そこにいるよって言われたらハッキリ分かるようになるじゃん。でも見えない人には全然見えなくて、そこにいるって指摘してもインチキ霊能者と思われてつらい *目次 [#a57cc82e] #contents *主な議題 [#i6dca174] -傍受 -なりすまし -改ざん *雑多 [#w54c7c74] セキュリティ上では万全ではない（通信を傍受されたりフィッシング詐欺に遭ったりする危険性がある）ようです。それを防ぐ仕組みとしてサーバー側でHTTPSで必ず接続するようにとブラウザに指示するのが、HSTSの設定です。 Hypertext Strict Transport Security（HSTS） HSTSの設定は2回目以降のアクセスについてHTTPのURLをブラウザに打ち込んでも、HTTPSでアクセスさせる仕組みです。 しかし、初回のアクセスについては、HTTPでアクセスすることがあり得るので、セキュリティは万全とはいえない状態です。（万全とはいえないケースについてはこちら） プリロードHSTS そのため、HSTSをさらに確実にするために「プリロードHSTS（Preload HSTS）」という仕組みがあります。なんかめっちゃ頑張ってサーバ側で設定して、サーバからのレスポンスヘッダに一項目追加すると、できる。Apacheでmod_headersが使えるサーバーなら.htaccessかhttpd.confに一行書けばよい。Header set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"。 PEM root.pemというのがroot認証のときに必要なものらしい。中身をみると、BEGIN CERTIFICATEのようなやつが書いてあって、あ、これがそうだったのねという感じになるね。 https://www.ecoop.net/memo/archives/guide-for-pem.htmlのようになっていて、これを知っていると、ログでPEM吐いてんなあとわかる。 証明書チェーンの全てを含む場合 テキストエディタで以下のファイルを開き、内容をコピーして .pemファイルに貼り付けます 発行されたサーバー証明書ファイル 中間証明書ファイル root 証明書ファイル .pemファイルには、上記のの順番で貼り付けてください。また、各証明書の開始タグと終了タグを省略することはできませんので注意してください。 x.509 証明書を発行するためのCAの構造を規定する規格 これ読んだほうが良さそう https://securityblog.jp/security_wordlist.html CAは公開鍵が正しいことを保証するもの。 オレオレ証明書は暗号化できているが、改ざんと通信相手が正しい保証が得られない。 Forward Secrecy(あるいはPerfect Forward Secrecy, PFS)は、全ての暗号化された通信を記録しておき、後からある期間の鍵を盗んだことができたとしても、それ以前に記録しておいた通信は復号できないという性質を指す。鍵交換にECDHEまたはDHEを使っている場合はPFSであると言うことができる。なお、ECDHE/DHEのEは"Ephemeral"のEである。 https://qiita.com/harukasan/items/fe37f3bab8a5ca3f4f92 これしっかりしている文章だからちゃんと勉強 クライアントが証明書の正当性確認するプロトコルはOCSP Staplingと呼ばれている。HTTPS通信を行う際には、証明書が失効していないか確認するため、OCSP Responderに証明書の正当性を確認する必要がある。HTTPS通信の度にOCSPリクエストを行わなければならないため、OCSP responderが低速であった場合、大きなボトルネックになる。 TLSの共通鍵通信を可能にするまでの流れを TLSハンドシェイクというらしい cert rotation HTTPSで通信するときに、サーバの証明書交換をdowntimeなしで行うための方法 サーバ側ではサーバ証明書情報を置く必要がある SSLは公開鍵で共通鍵を渡して通信する方法。 セッションはクッキーと似ていますが、必要な情報をクライアントではなくサーバ側に保存します。その為、よりセキュアに利用することができます。ここではセッションの使い方について解説します。 クッキーはサーバがユーザのブラウザのメモリに保存するというスタイル。 セッションは、サーバに必要な情報をメモして、セッションIDだけブラウザ側のクッキー「など！！」に保存してもらうスタイル。 nmap --script ssl-enum-ciphers -p 443 example.com httpサーバなりなんなりのSSL/TLSバージョンの有効無効状態などの詳細な情報を得ることができる。相手サーバのDistとかも可能 *悪い事例 [#lc64db9c] **IoT [#xae7d42f] -スマートキーの弱点突く車盗難 微弱電波中継し解錠 -Amazon Bottonは何も入っていないように見えるけど、セキュリティは死ぬほど頑張っている -そうかグーグル翻訳は「情報の修正を提案」で調教できるんだ -ぐーぐるほんやくがViginal cum shotになった時期がある **怪しいセキュリティ対策 [#a48b7425] -パスワード別送 --日本のガラパゴスルール --日本国内の認定制度である「プライバシーマーク」を取るために、2010年から「添付ファイルに対するセキュリティ対策」が必要 --既存システムへの変更不要な方法として、反証困難な別送方式を取ったと予想できる --盗聴対策には効果がなし、誤送信を防ぐ能力はある --添付ファイル付きメールとパスワード通知メールを、システムで自動的に同じ相手に送るような運用があるらしいがこれはマジでセキュリティ的に意味がない *公開鍵暗号方式 [#d4d9a7cb] -公開鍵暗号化方式の本質は、暗号化のためのパスワードと復号化のためのパスワードが別々にあるということ --一緒だとそれが流出しただけで死ぬ --そして暗号化のためのパスワードは公開しておいても全く問題が発生しない（意味わからんそのサーバにしかわからないデータが生成されるだけなので） *SSL/TLS [#qf94a9bc] **まずここ見て [#tcef0890] -暗号化と電子署名を理解する必要があります。 --電子署名を先に理解する必要があります。 --暗号化では公開鍵で暗号化して秘密鍵で復号化しますが、電子署名では秘密鍵で暗号化して公開鍵で復号化します。前者のイメージが強いですが、両方向できます。 -電子署名 --秘密鍵を使って暗号化すると、公開鍵でのみ復号できます。 --公開鍵は広く知られる前提であるため、機密性の確保はできませんが、「サーバ A の公開鍵で復号できた」通信というのは、「発信源が間違いなくサーバ A であり、内容は改竄されていない」という完全性・真正性が確保できます。 --これは主に『デジタル署名 (Digital-Signature)』で使われます。 --発信源は (元ファイル, 元ファイルのハッシュを秘密鍵で暗号化したもの) をペアで送り、受取人は元ファイルと元ファイルのハッシュ (公開鍵で復号化したもの)を得てそのハッシュが元ファイルから得られるかを確認するということをします。 -暗号化 --公開鍵を使って暗号化すると秘密鍵でのみ復号できます。 --秘密鍵は原則サーバ A 以外には知られないため、サーバ A のみが復号でき、機密性が確保できます。 --しかし、誰のものかわからない公開鍵を使って暗号化してはいけません。知らない第三者だけに読める暗号文 ができてしまいます。そのため、公開鍵証明書 という、公開鍵の出どころを第三者（認証局）が証明する仕組みが要ります。 ---証明書の中に公開鍵自体が埋め込まれているのが普通です。 ---証明書は、「公開鍵に第三者の電子署名をつけたもの(署名付き公開鍵)」です。 ---認証局の電子署名が正しいかを判断するために、CA certificate (= 電子証明書を発行する認証局自身の公開鍵が含まれた電子証明書で、予めデバイスなどに保存されている必要がある。) と 証明書失効リスト (秘密鍵をうっかり公開してしまうなどして、無効になってしまった公開鍵の一覧が書かれたリスト) を使って公開鍵の有効性を確認する方法があります。 ---CA証明書 (公開鍵。デバイスに保存される必要) と、CA秘密鍵 (秘密鍵。認証局に保存される) は、誰でも作ることができます。 -SSL/TLS --TCP 3 wayハンドシェイクとTLSセッションが終わると、サーバがデジタル証明書 (認可局が電子署名した公開鍵) を送ります。 --受取人は、電子署名の検証のために認証局のCA証明書（認証局の公開鍵）を予めインストールしている必要があります。 **用語 [#oc08cde2] -TLS (Transport layer security) --TLSは、公開鍵暗号方式で共通鍵の受け渡しを行い、あとは受け渡した共通鍵を使って共通鍵暗号方式（秘密鍵暗号方式）でやり取りすることで、通信の安全性を高める仕組み -SSL (Secure sockets layer) --SSL, TLSはSSL 3.0までバージョンアップ語TLS 1.0に名前変更 --TLS 1.2以前のものは多くの脆弱性がある、TLS 1.3はまだ1個しか見つかっていない。 --TLSは証明書でなりすましを防ぎ、公開鍵方式で暗号化するもの。 -SSLは1990年代中頃、当時の主要なブラウザ Netscape Navigator を制作していたNetscape社で開発 --SSLプロトコルの最初のバージョンである「SSL 1.0」は、プロトコル自体に重大な欠陥があったの非公開 --次のバージョンである「SSL 2.0」が1994年11月にリリースされ、実際にブラウザへ実装されたのが 1995年3月にリリース (Netscape Navigator 1.1) ---外部のセキュリティアドバイザーに全く相談せずに開発されたため、のちに重大な脆弱性が発見 -1995年11月に「SSL 3.0」がリリース --設計は根本から見直され、これがのちに紹介する現在のTLSプロトコルの基本設計に --2014年9月に仕様上の脆弱性（POODLE）が発見され、根本的な対処法としては「SSL 3.0」を無効化 --そのため、2015年6月にはIETF(インターネット技術タスクフォース)により「SSL 3.0」の使用は禁止 -1996年5月、SSLをNetscape社からIETFへ移管するために、TLSワーキンググループが結成 --これは当時のブラウザにおいて、Netscape社のNetscape NavigatorとMicrosoft社のInternet Explorerの激しいシェア争いが行われる中、安全なインターネット通信を実現するためにセキュリティプロトコルとして広く使われ始めたSSLを、セキュリティ専門家を交えた第三者機関で開発するための措置 -1999年1月、TLS（Transport Layer Security）という名称で「TLS 1.0」がリリースされ、実質SSLからTLSへと移行 --「SSL 3.0」との違いはわずかですが、両バージョンの互換性はありません。 -2006年4月にはTLSの改良として「TLS 1.1」がリリースされ、それまでに発見された攻撃手法に対応することを目的としたセキュリティの強化が行われました。 -2008年8月には現時点で最新の「TLS 1.2」がリリースされ、脆弱性のある古い仕組みの排除や、最新の暗号化に対応するなど、安全性を高める改良が行われています。 -2017年12月現在、次のバージョンとなる「TLS 1.3」がドラフトとして提案、2018年8月に正式リリースされている。 -SSL 3.0以前、TLS 1.0, 1.1は、POODLEHeartbleed、FREAKなど既に発見されている脆弱性がありマジ危ない。2020年にはdeprecated -SSLには複数の認証レベルがある。 -ドメイン認証（ドメイン名の利用権の確認）あとでこれはちゃんと勉強する必要がある https://jp.globalsign.com/ssl-pki-info/ssl_beginner/types-of-ssl.html -企業実在認証（組織の法的実在性確認）Extended Validation(EV)証明書 ドメイン所有者について認証局が実在証明を厳格に行なったのちに発行される -EV認証（組織の法的物的実在性確認。最強。アドレスバーに鍵のマークと組織名が表示されるようになる！）Organization Validation(OV)証明書 組織情報の審査を経てから発行されるDomain Validation(DV)証明書 ドメインの管理権限を元に発行される -TLSのバージョン対応は、OSとブラウザのバージョンを上げればよいだけ！サーバサイドはもう少し考える必要あり。 --TLS 1.2で3DESという暗号化方式には脆弱性がある --https://tosebro.hatenablog.com/entry/2016/12/26/022240 --そもそも暗号化方式はサーバが決めるんじゃないの？クライアントがこのSSL, この暗号化方式でやりましょうと指定できるものなの？なんかできるっぽいな（駄目ならこれでも行ける？と行ってサーバが断らないのが問題ぽい） -詳しめの暗号化方式の説明 --Cipher suitesとは、ひとくちにTLSと行ってもいろんな暗号・ハッシュがあるので、それらのセットをcipher suitesと呼びましょうという話 --2019/5現在、Java OpenJDK 1.1 + TLS 1.3だとハンドシェイクに問題があるので、結局はTLS 1.2を使うのが丸いらしい。 --apache や nginx の設定をしたことがあれば以下の様な行を見たことがある人も多いのではないでしょうか。(※ 下記は nginx の設定。apache の場合は SSLCipherSuite です。) --ssl_ciphers AES128-SHA:AES256-SHA:RC4-SHA:DES-CBC3-SHA:RC4-MD5; --まあこれだとイミフなのでopenssl ciphers -vとすることで、TLSのバージョン・Kx, Au, Enc, Macのセットが出てくる。 --暗号スイートの名前 AES128-SHA --プロトコルのバージョン SSLv3 --鍵交換に使われる暗号化アルゴリズム Kx=RSA。Kx は Key Exchange の略。 --認証に使われる暗号化アルゴリズム Au=RSA。Au は Authentication の略。 --アプリケーション層の暗号化に使われる暗号化アルゴリズム Enc=AES(128)。Enc は Encryption の略。 --http://tkengo.github.io/blog/2015/12/01/https-details/ このサイトがtechnicallyに何をやっているのかをちゃんと説明していて面白い。ここで書かれている鍵がどの段階で使われているのかが書かれていて面白い --http://tkengo.github.io/blog/2015/12/01/https-details/ -SSLの通信方式に関する設定はサブドメイン単位で設定できるっぽい --「WebサーバーにインストールされているSSLサーバー証明書を確認」みたいな方法でSSLの確認ができる --https://www.ibm.com/support/knowledgecenter/en/SS7MHN/Talent_Suite_Release_Notes_1_4_6/how_do_you_know_browser_supports_tls_ssl.html -サポートしているSSLのバージョンとCypher Setは以下で可能 --nmap --script ssl-enum-ciphers -p 443 home.wakatabe.com -DSだとWEPなどで乗っ取られる --AESとかも脆弱性がある。 --これもどういう脆弱性なのか説明できたほうがいいなあ -SSL certificates are made as a chain from root CA to user's (service's) certificate. -なお、サーバがサポートするSSLバージョン、Cypher suitesと、ブラウザのそれが全くマッチしなかったら。Chromeの場合にはブラウザレベルでERR_SSL_FALLBACK＿MINIMIUM＿VERSION的なエラーがでて通信はできない（当たり前だが、これはサーバ側の設定で平文で送るみたいなこともできるかもしれない） -各脆弱性は脆弱性があるから使えない！ではなく、現実的なmitigationを行っているかも考えるべき https://stackoverflow.com/questions/31183297/ssl-connect-fails-with-ssl-error-syscall-error 透明性の証明 証明書の誤発行を防ぐ新たな技術 パブリックなSSL証明書は、認証局(CA:Certification Authority)によって発行され、その内容が保証されます。 しかし、近年認証局が不正アクセスを受けて偽のSSL証明書を発行したり、誤って不正な証明書をSSL発行したりという事件がありました。 そこでGoogle社が考案したのが、不正なSSL証明書を早期に発見・検知するための仕組みであるCTを(Certificate Transparency)です。これは、現在RFC6922として規格化され、Google Chrome などが対応しています。 CTは認証局が証明書を発行する都度、全ての証明書発行の証跡を、第三者の監査ログに記載する仕組みです。主に、ウェブサイトの運営者やドメイン名の管理者が、その監査ログサーバ（以下「ログ））を確認することで、自分のドメインに対して不正な証明書や、ポリシー外の認証局からの証明書が発行されていないかを検証することができます。それにより利用者が不正に発行された証明書を信頼することを防止します。 CTはあくまで証明書の信頼性を高めるための追加の仕組みであり、これまでの証明書の検証の仕組みが無くなるわけではありません。 ログに証明書を提供すると、ログからはSigned Certificate Timestamp（SCT）と呼ばれるデータが返されます。SCTは、ログが特定の時間内（「Maximum Merge Delay (MMD)」と呼ばれます）に証明書データが格納されたことを保証するタイムスタンプ情報です。ウェブサーバなどのSSL/TLSサーバはログから取得したSCTを、証明書と一緒にブラウザなどのSSL/TLSクライアントに提示しなければいけません。SSL/TLSクライアントは、証明書とSCTを使って、ログの中にその証明書のデータが登録されているかどうかを確認することができます。 CT対応しなかった場合、Google ChromeでEV SSL証明書では2015年2月以降グリーンバーが表示されなくなり、OV SSLならびにDV SSL証明書では2016年6月以降警告が表示されます。 実はプライマリ・サーバとセカンダリ・サーバの違いは、ゾーン情報をローカルのゾーン情報ファイルから入手するか、ほかのDNSサーバ（プライマリ・サーバ）から入手しているかの違いでしかない。問い合わせ側は特に区別はしない（できない）。リゾルバは、通常は複数のDNSサーバからランダムに選択して利用することになる。 これを自ドメインに対する「オーソリティ（権限）」を持つと表現する。SOAレコードはドメインにおけるオーソリティを記述するレコードである。 ただし、より正確にはオーソリティを持っていると見なされるのは、上位ドメインのゾーン情報で、そのドメインのDNSサーバとして指定されたサーバ（NSレコードに記載されたサーバ）に限られる。ドメイン・ツリーに参加していないサーバが、いかにその情報を知っていると主張しても、外部からはそれが正しい情報かどうか確認できないからだ。 認証のためにCNAMEを指定させることもある。これはホストofijeoirj08uru08r3.google.hostingservice.comみたいなものにダイレクトさせて、そもそも SPF：実際に送られてきたIPに直接、あなたの住所としてありえるものはどれですか？と問い合わせる方法。複数IPから送る可能性があるので、問い合わせはinculdeみたいな形で書かれる。 SPF (Sender Policy Framework)とは、 電子メールの送信元ドメインが詐称されていないかを検査するための仕組みです。 送信側は、あらかじめ自ドメインの権威DNSサーバ上に自ドメインの送信者がメールを外部に向けて送出する可能性のあるメールサーバのIPアドレスの一覧を記述（公開）する。SPFの仕様は、 RFC4408(*1)で定められています。 インターネットでメール送信に使用されるプロトコルであるSMTP (Simple Mail Transfer Protocol)は、 差出人のメールアドレス(Fromアドレス)を自由に設定することが可能です。 このため、 送信元を偽った「なりすましメール」を簡単に送ることができてしまい、 これが迷惑メールに利用されてきました。 SPFは、こうしたメールアドレスにおけるなりすましを防ぐための技術の一つで、 DNSを利用するのが特徴です。 ドメインをSPFに対応させるには、 そのドメインのゾーンデータにSPFレコード(*2)という情報を追加します。 SPFレコードには、 そのドメイン名を送信元としてメールを送ってもよいサーバのIPアドレス等を記述します。 一方、SPFに対応したメール受信サーバは、 メールの受信時にそのメールの送信元となっているドメイン(*3)のSPFレコードを、 DNSで問い合わせます。 送信元のサーバがSPFレコード中で許可されていない場合は、 送信ドメインの詐称が行われたと判断して、 受信を拒否するなどの処理を行います。 つまりSPFは、送信元サーバのIPアドレスとDNSを利用して、 あらかじめ想定された送信元以外からのなりすましメールを検出できるようにする機構で、 より多くのドメインがこの仕組みに対応することで、 その効果が高くなります。 電子メールの送信者偽称を防ぐ送信ドメイン認証技術には、ここで説明する「Sender Policy Framework（SPF）」のほかに、「DomainKeys Identified Mail（DKIM）」、「Sender ID」など様々な方式が標準化されている。その中でもSPFは、他の方式に比べて既存システムに影響を与えず早期に導入できる点が評価されている。 https://salt.iajapan.org/wpmu/anti_spam/admin/tech/explanation/spf/ SPFでは、送信元のIPアドレスを元に認証を行うため、認証時に送信元ホストが本来の送信元に属していないようなケースでは認証に失敗する。 Sample 6: メールを送信しないドメイン 管理しているドメインが全くメール送信しない場合には、“-all”を利用してその旨を公開できる。example.org. IN TXT "v=spf1 -all" これは面白い BoringSSLはOpenSSLのheartbleedのあとのGoogleによる代替 https://ascii.jp/elem/000/000/908/908495/ *パスワードの受け渡し方法 [#v1f2729a] -DH鍵交換 *DDoS [#w66756da] -単純な嫌がらせ --そもそもDDoS攻撃だけでは、マルウェアのように不正にデータを盗んだり、改ざんしたり、消去したりといったクラッキング行為を行うことはできません。 --嫌がらせの動機は様々でしょうが、サイト運営者が困ることを目的としてDoS攻撃またはDDoS攻撃を仕掛ける人が一定数存在しています。 -Economic DoS Attack --被害者に経済的ダメージを追わせることを目的としたサービス --競合サイトをアクセスしづらい状態にするなどなんらかの営利目的を持っての妨害行為としてDDoS攻撃を仕掛ける場合があります。ライバル企業の犯行の可能性が疑われることも珍しくありません。 -Distributed Denial of Service attack --DRDoS攻撃という、攻撃対象になりすましてリクエストを大量に送ってその返信で相手に負荷集中させるという方法もある。 -抗議活動 そのサイトの運営元に対するなんらかの抗議活動としてDDoS攻撃を仕掛ける場合があります。 政治問題に対する抗議活動として、DDoS攻撃を仕掛ける事例は過去に様々な国の政府を対象に実行されています。 -脅迫行為 企業などの特定の組織に対して、DDoS攻撃を事前に予告し、DDoS攻撃を引き換えにして身代金等様々な脅迫行為を行う場合があります。 --特に2017年から仮想通貨サイトやFXサイトに対して、DDoS攻撃を悪用した脅迫行為が相次いでいます。 --https://www.jpcert.or.jp/newsflash/2017092101.html -他のサイバー攻撃との併用 --サイバー攻撃には、DDoS攻撃以外にも存在し、同時に複数のサイバー攻撃を用いることがあります。 --例えば、DDoS攻撃を仕掛け、管理者がDDoS攻撃の対処をしている間に他のサイバー攻撃を行うなど、DDoS攻撃を目くらましとして使用される場合があります。 -事例 --ネットインフラ支援サービス企業を狙ったDDoS攻撃(2016年) --インターネットの基盤サービスを提供する企業を狙った大規模なDDoS攻撃攻撃が行われ、ツイッターやアマゾンだけでなく、ソニー、米決済大手ペイパル、ニューヨーク・タイムズなど米メディア大手、米動画配信大手ネットフリックスなどで障害が発生しました。 --マルウェア「Mirai」を使用した、史上最悪規模のDDoS攻撃(2016年) ---2016年10月にMiraiが行ったDDoS攻撃では、米国のセキュリティ情報サイトやDNSサービスを提供する企業が停止し、連鎖的にTwitterやSpotifyといったサービスも利用できなくなりました。 --パレスチナ爆撃抗議事件(2012年) --イスラエルによるパレスチナ攻撃に抗議したハッカー集団「Anonymous(アノニマス)」は、イスラエルによるパレスチナ攻撃の抗議活動として、イスラエル政府が保有する複数のサイトに対してDDoS --この攻撃でイスラエル政府や銀行系を中心に、約600におよぶウェブサイトがダウン *OAuth [#v35342e2] -OAuth 2.0 --http://krr.blog.shinobi.jp/gae/google%20app%20engine%20oauth%E8%AA%8D%E8%A8%BC%E3%82%92%E5%88%A9%E7%94%A8%E3%81%99%E3%82%8B --OAuth2は「ユーザ／パスワードで本人確認」する仕組み（認証）ではありません。 --正しくは「特定のデータへ特定の操作を許可」する仕組み（認可）です。 -APIを悪意あるユーザから守るための仕組み --クライアントアプリが認可サーバにアクセストークンを要求し、認可サーバがユーザに権限譲渡の意志を確認し、認可サーバがアクセストークンをクライアントアプリに発行する、というところの標準化を行ったもの(RFC 6749) --「ユーザーAのデータにアクセスしてよいか？」という要求を、（悪意ある）ユーザーBのクライアントアプリが認可サーバーに要求した場合に、ユーザーAさんに確認が必要ということだと思います。 --client, resource server, authorization server, user, notorious userの5人が出てくる --OAuthでログインしている間はsession["profile"]というdict<string, string>が発生する、keyとしてはname, emailなどがある。 --トークン=xxのサービス上で△△の代わりにooができることを証明するもの。 -[[このスライド>https://www.slideshare.net/ph1ph2sa25/oauth20-46144252]]の40pがめちゃわかりやすい。 --擬人化良いな。セキュリティ対策についても書かれていてとても良い感じ。 --[[OAuthそのものは認可のためのものなので、認証の代わりに使うとめちゃくちゃでかいセキュリティホールができる>https://www.sakimura.org/2012/02/1487/]] --[[そもそもOAuthをログインとして使うのは上のパラダイムとは違くない？？>https://dev.classmethod.jp/architecture/deep-think-about-oauth-authentication/]]あと、[[歴史的になぜOAuthがソーシャルログインに使われるようになったか>https://www.eisbahn.jp/yoichiro/2016/03/social_login.html]]の経緯。これは禁断の術みたいに言われているケースもある。そもそもなんでログインっぽい動作ができるのか謎 --[[アクセストークンには内包型と識別子型がある>https://qiita.com/TakahikoKawasaki/items/970548727761f9e02bcd]]それと、そもそもトークンをサーバで止めるかどうかという分類もある。 -https://medium.com/google-cloud-jp/gcp-%E3%81%A8-oauth2-91476f2b3d7f --https://medium.com/@yfuruyama --これいい記事 *踏み台 [#v6d280af] bastion hostを直訳すると要塞ホストだが、確かに踏み台は要塞ホストの一種と言える。 ただ、日本語で「要塞ホスト」と書いてしまうと、「踏み台」という意味は読み取れなくなるな。 AWSではbastion hostは踏み台と思えばいいみたい。 *所有権確認 [#w7782035] -合言葉 --A. このドメインが私のです！ --B. ほんまなら、ドメインに問い合わせたら合言葉を言うようにしといて --A. はい ---合言葉を言えたら実際にAさんはドメインを持っていることがわかる -通常 DNS TXT(テキスト)レコード で合言葉を設定する --特定のホスト(ドメイン・サブドメイン)に関連づけるテキスト情報の事。制御タイプの一つ。Text の略。 --主に送信メールアドレスの他者によるなりすましなどを防ぐために使われます。その場合のTXTレコードはSPFレコード(Sender Policy Framework)とかSenderIDとも呼ばれます。同じようになりすましメールを防ぐ新しい技術として DKIM(DomainKeys Identified Mail) というのもありすが、こちらもTXTレコードによって設定します。 *電子透かし＝ウォーターマーク [#z5400995] -実際には見えないし影響しないけれど、何らかのキーワードでデータを埋め込む技術のこと。無断転載画像に電子すかしを行って作者を明示することで誰が実際にその絵を書いたかがわかるようになるなどで使える。 --https://twitter.com/furuya1223/status/1135897754947874816?s=19 -仕組みを理解していない。。 *Tink [#r276dacc] -Tink（Google のオープンソース暗号ライブラリ） -Authenticated Encryption with Associated Data (AEAD) --AEAD primitive (Authenticated Encryption with Associated Data) provides functionality of symmetric authenticated encryption. *エンベロープ暗号化 [#b437db41] -エンベロープ暗号化 --公開鍵暗号は遅く、大きいデータを暗号化できない --一般的な暗号化方式では、平文のデータを何らかの鍵を使って暗号化することで保護します。このとき、この鍵がデータとセットで盗まれてしまうと、暗号を解かれてしまい、生のデータを見られてしまいます。そこで、データを暗号化した鍵を、別の鍵でさらに暗号化することでデータをより強固に保護しよう、というのがエンベロープ暗号化の考え方です。 -用語 --データ --暗号化されたデータ --データを暗号化するための鍵（データキー = DEK） --暗号化されたデータキー --鍵を暗号化するための鍵（マスターキー = 鍵暗号鍵 = KEK） -KEK, DEK は両方とも対称鍵 -使い方 https://cloud-aws-gcp.hateblo.jp/entry/2019/11/27/102334 --Master Key -> Plain Data Key + Encrypted Data Key --Master Key + Encrypted Data Key -> Plain Data Key --Plain Data Key + Data -> Encrypted Data --Plain Data Key + Encrypted Data -> Data --Plain Data key は使ったらすぐ捨てる --Encrypted Data key は Encrypted Data と一緒に保存する (一緒にというのが大事！) -行レベルというのが大事。BQ はユーザの kek のしか見ることができない。 --ユーザは kek を KMS に置く --ユーザは kek pointer, flk = kek(dek) を持ってくる。 --BQ は kek pointer にある KMS の kek を使うために delegate が必要。 --BQ は KMS に kek(dek) を送って dek を取得 (kek は KMS を決して離れない) --BQ は dek を使ってデータを復号化したり暗号化したりできる。 --BQ は dek をすぐ捨てる https://cloud.google.com/bigquery/docs/reference/standard-sql/aead-encryption-concepts#cloud_kms_protection クエリの実行時に、KEYS.KEYSET_CHAIN 関数を使用して、KEK の KMS リソースパスと、ラップされた DEK の暗号テキストを指定します。BigQuery が Cloud KMS を呼び出して DEK をラップ解除し、その鍵を使用してクエリのデータを復号します。ラップ解除された DEK のバージョンは、クエリの期間中のみメモリに保存され、その後破棄されます。 *耐性ダンパー性 [#gfded0de] あらゆるICカードの安全性は耐タンパー性があってこそ成り立っている マイナンバーカードについて「悪用された場合には直ちにチップが破壊をされるという仕組みになっております」と総務大臣が記者会見で言っていたのだが、本当？チップが破壊されるなんて初めて聞いた。 https://soumu.go.jp/menu_news/kaiken/01koho01_02001178.html *MAC randomization [#d4694b72] IP アドレスを抜かれてもプライバシー上問題ないの、IPv4 が IP アドレスの個数について楽観的すぎたから？と思ったけど、冷静に考えると IPv6 が普及したら一意になるからどうなってるんだろうだし、そもそも MAC アドレスで所有者特定！みたいな話にならないのなんでだろう（紐づけられないから？） なってるからpixelとかだとmacアドレスをrandomizeしてるんでない？ え、初めて知りました（ということは IPv6 もランダマイズする？と思ったら MAC がランダマイズしてないとまずいよねみたいな実装を発見していました https://networkacademy.io/ccna/ipv6/ipv6-on-windows） *X509証明書 [#b89b05b0] -以下みたいなやつ $ openssl s_client -connect google.co.jp:443 -showcerts </dev/null | openssl x509 -text -noout Connecting to 2404:6800:4004:825::2003 depth=2 C=US, O=Google Trust Services LLC, CN=GTS Root R1 verify return:1 depth=1 C=US, O=Google Trust Services, CN=WR2 verify return:1 depth=0 CN=*.google.co.jp verify return:1 DONE Certificate: Data: Version: 3 (0x2) Serial Number: 74:31:44:5a:51:8c:67:31:12:7a:ec:f8:7c:a7:35:fb Signature Algorithm: sha256WithRSAEncryption Issuer: C=US, O=Google Trust Services, CN=WR2 Validity Not Before: Feb 3 08:38:16 2025 GMT Not After : Apr 28 08:38:15 2025 GMT Subject: CN=*.google.co.jp # 認証局の情報。2025 年現在はホストをここで検証することを禁止するように RFC が制定されつつある。 Subject Public Key Info: Public Key Algorithm: id-ecPublicKey Public-Key: (256 bit) pub: 04:85:73:7c:1f:29:83:ff:df:7a:b7:53:5f:38:9a: 24:7b:18:19:b9:88:59:f3:8a:a4:ec:b4:3d:63:66: 1d:78:d2:e2:5b:ef:32:1f:c3:ad:09:e7:a8:81:38: 56:e8:68:e5:d5:11:cd:71:74:2e:96:d3:64:12:29: 9e:d3:aa:fa:14 ASN1 OID: prime256v1 NIST CURVE: P-256 X509v3 extensions: X509v3 Key Usage: critical Digital Signature X509v3 Extended Key Usage: TLS Web Server Authentication X509v3 Basic Constraints: critical CA:FALSE X509v3 Subject Key Identifier: E6:9E:D0:55:09:41:DB:3F:72:8E:9B:69:22:45:ED:89:6F:28:04:E5 X509v3 Authority Key Identifier: DE:1B:1E:ED:79:15:D4:3E:37:24:C3:21:BB:EC:34:39:6D:42:B2:30 Authority Information Access: OCSP - URI:http://o.pki.goog/wr2 CA Issuers - URI:http://i.pki.goog/wr2.crt X509v3 Subject Alternative Name: DNS:*.google.co.jp, DNS:google.co.jp X509v3 Certificate Policies: Policy: 2.23.140.1.2.1 X509v3 CRL Distribution Points: Full Name: URI:http://c.pki.goog/wr2/oQ6nyr8F0m0.crl CT Precertificate SCTs: Signed Certificate Timestamp: Version : v1 (0x0) Log ID : 4E:75:A3:27:5C:9A:10:C3:38:5B:6C:D4:DF:3F:52:EB: 1D:F0:E0:8E:1B:8D:69:C0:B1:FA:64:B1:62:9A:39:DF Timestamp : Feb 3 09:38:17.013 2025 GMT Extensions: none Signature : ecdsa-with-SHA256 30:45:02:21:00:F0:74:AC:31:26:E6:26:77:BE:34:62: A4:F3:8C:07:21:64:A9:5F:E9:6B:03:F3:B6:94:23:92: 1E:C0:43:37:6D:02:20:59:6C:B4:11:FC:E0:02:C1:B4: E3:74:AD:3B:3F:17:02:B0:6F:3B:66:44:9E:9F:9F:FB: 11:7E:09:16:8B:02:F2 Signed Certificate Timestamp: Version : v1 (0x0) Log ID : 13:4A:DF:1A:B5:98:42:09:78:0C:6F:EF:4C:7A:91:A4: 16:B7:23:49:CE:58:57:6A:DF:AE:DA:A7:C2:AB:E0:22 Timestamp : Feb 3 09:38:17.222 2025 GMT Extensions: none Signature : ecdsa-with-SHA256 30:46:02:21:00:B7:69:46:0F:D8:C4:05:39:24:28:7C: 7E:F8:57:EE:C7:06:2A:7C:5D:34:F8:C3:09:A1:52:97: 57:E7:B4:71:78:02:21:00:FA:63:63:68:92:9A:5E:D0: E5:DA:FC:73:7E:B7:D4:8C:DE:A4:F4:6C:E3:45:47:0F: 24:06:B8:C5:D4:E9:0C:CB Signature Algorithm: sha256WithRSAEncryption Signature Value: 91:59:da:e6:ed:9e:e7:d6:6a:5f:c8:89:36:3f:22:7a:9e:64: 1b:8c:52:70:2d:5c:0e:c6:58:f6:bb:69:34:b2:c7:24:fe:fb: 55:f3:a4:b0:0e:f5:0e:0c:0e:31:83:4a:02:cf:7f:c0:36:1b: 3c:3c:5f:db:73:5b:80:ed:a3:fd:3e:ea:70:f9:75:db:44:67: 15:5c:c3:9a:46:cd:55:1a:0c:2a:8c:9c:f6:5a:3f:aa:52:2f: 96:8b:8d:28:e9:62:ae:a0:ac:fe:97:19:9c:56:9e:56:68:3f: d0:88:59:d6:5e:9b:ba:1a:d9:18:d2:29:df:c3:66:15:f4:33: df:ca:95:08:a7:6f:93:18:a3:c6:8b:75:7a:33:83:f9:77:1e: 3c:b6:2d:d3:95:dd:3d:5a:5e:f3:e0:df:7c:b1:90:77:0c:f9: 05:69:7a:f5:37:16:55:54:a8:f2:f8:be:d9:dd:4b:0e:64:c0: a1:5d:e4:ed:ac:88:05:fa:d0:56:63:c6:8f:50:92:4e:c7:a4: b3:5d:af:1b:79:6d:8f:97:61:2e:72:ef:73:3e:85:33:8a:c6: 66:f4:2f:14:11:8a:8f:90:15:6c:0b:2c:a7:a9:1f:b0:5b:3b: 3d:d4:4c:8a:f9:c9:ba:54:cb:9d:7e:f6:9b:a8:a5:9e:06:8a: 63:fa:97:12 - Subject: CN=*.google.co.jp # 認証局の情報。 --2025 年現在はホスト名検証をここで検証することを禁止するように RFC 9525 (PKIX) や RFC 5280 (nternet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile) などで制定されつつある。 --かわりに SAN を使ってホスト名検証する。 -Basic Constraints --CA:TRUE の場合、認証局そのものであることを表す。これは通常自己署名であることを意味する --普通は CA:FALSE で返ってくるはず。 |
