OSの9.xの課題

OSの講義の9.xの問題を解く

これが正解だぜ(どや)みたいなノリでは書いてないです、ただの平均的な技術力を持っているB2が解いているだけ

課題の取り組みをブログで書いてもいいという許可をもらった上で記事を書いてます

最新の課題内容であることや、答えが正しいかどうかは保証しません

このブログの情報で読者に何らかの不都合が生じても著者は責任は取らないです


9.1 Backup

このページの問題を解く

情報工学を学ぶものは、自分で運営する Web Service の一つや二つを持っているだろう。

自分自身のファイルのバックアップ戦略について Cloud と 自分の Web Service を含めて、提案せよ。

以下のことを考慮すること。

    最低、3重のコピーを維持する必要があるのは何故か。
    ファイル履歴はどこまで持つべきか。
    Apple の Time Capsule が Web Service に対して使用できないのは何故か。
    バックアップに要するコストは妥当か。

答え

自分は技術ブログを運営している。Markdownで書いてhugoでhtmlとcssを生成して、GitHubのレポジトリにアップロードして、Github Pagesで公開している。

バックアップ戦略に関して、バックアップを失う/取れなくなるリスクが、バックアップの作成、リカバリ、保持の段階で現れるということを考えると最低3重のバックアップは取る必要がある。3重とはいえ、バックアップの作成、リカバリ、保持の手段が同一であると意味がない。例えば、Time Capsuleで3つのNASバイスにバックアップを取っても、リカバリの段階でトラブルが起きてしまった場合に3つのNASバイスのうちどれからもデータを復元することができなるなる。つまり、同一の方法でデータを保持することは何台デバイスを増やしても結局は「1つのバックアップ」でしかない。よって、3つの異なる方法でバックアップを3重に取る必要がある。

上記を踏まえた上で自分が取るバックアップ戦略は以下の通りである。

GitHubMarkdownで書いた記事のレポジトリとhugoで生成したhtmlのレポジトリの2つを持っている。本来GitHubはバージョン管理ツールとして使うのだが、GitHub自体はユーザが削除しない限りパブリックリポジトリを利用できるまま保とうとするのでバックアップの手段として捉えることができる。データを失うリスクとして、レポジトリの中身がDMCAテイクダウンポリシー、コミュニティガイドライン、あるいは利用規約に反するとGitHubに判断されてしまうことでレポジトリを自由に利用できなくなることが考えられる。

学科VMWebサービスを維持するのに必要なファイルを転送する。sshさえできればrsyncコマンドで復元が簡単にできる。問題は学科サーバがシャットダウンしてしまったり、学科サーバ側の問題でVMのデータが失われてしまう場合は復元できなくなることである。

SSDでファイルを保存する。バックアップできなくなるリスクはSSDの故障や紛失である。SSDは1万円ほどするが、自分の運営している技術ブログは未来には一種のポートフォリオとして使えるかもしれないので、データを失ったときの損害の方が大きいので、コストは妥当と言える。


9.1の感想

  • 色々考えてしまった

9.2 素因数分解を使った暗号化

このページの問題を解く


二重鍵暗号には二つの関数EとDを使う。

   E(D(x)) = x 
   D(E(x)) = x

となる。
E/D にはフェルマーの小定理を使った方式がある。mod は剰余類による演算を表す。剰余類では可換則や分配則がそのまま成り立つことを思い出そう。

p が素数で, a が p の倍数でない正の整数のとき

a^(p−1) ≡ 1 mod p

つまり、剰余類で指数乗の計算をすると、素数-1の時に1に戻ることを利用する。
二つの素数3,5を使った以下の関数

E(x)=x^11 mod15
D(x)=x^3 mod15

を二重鍵暗号として使うことができる。15は3と5の積である。11と3は、それを使って求めた鍵ペアである。(鍵ペアの条件は、 (3-1)(5-1) = 8 と互いに素な鍵k1、
 なk2だが、ここでは使わない)
7をメッセージとして、暗号化したら y になったとする。y を求め、以下の式を検算せよ。

   D(E(7)) = 7
   E(D(y)) = y

問題の目的

二重鍵暗号の関数EとDを使用して、メッセージ7を暗号化し、その結果をyとした場合のyの値を求め、さらに D(E(7))とE(D(y)) の関係を検算すること

関数EとDがそれぞれ公開鍵と秘密鍵の役割を果たしていて、

暗号化と復号のプロセスを通じて、これらの鍵がどのように動作するかを理解するというのがこの課題の最終目的

自力で計算するパターン

暗号化関数Eの計算

まず、メッセージ7を暗号化するための関数 E(7) を計算する E(7) = 711 mod 15

この計算を簡単にするために、与えられた情報 72 ≡ 4 mod 15 と 42 ≡ 1 mod 15 を利用する

まず、 72 ≡ 4 mod 15 という情報が与えられている

これは、7を2回掛けると、15で割った余りが4になることを示している

(a ≡ b mod cは本来、aとbをcで割ると同じ余りが出るという意味なので注意)

次に、 42 ≡ 1 mod 15 という情報も与えられている

これは、4を2回掛けると、15で割った余りが1になることを示している

711 は、 (72)4 × 72 × 7 と分解できる

72 ≡ 4 mod 15 なので、 (72)4 ≡ 44 mod 15 となる

さらに、 44 は、 (42)2 として考えることができる そして、 42 ≡ 1 mod 15 なので、 44 ≡ 12 ≡ 1 mod 15 となる

このように、与えられた情報を利用して、大きな指数の計算を簡単な計算に分解することができる

7^11
≡ 7^8 × 7^2 × 7 mod 15
≡ 1 × 4 × 7 mod 15
≡ 28 mod 15
≡ 13 mod 15

E(7) = 13 なる これは、メッセージ7を暗号化した結果yの値である

復号化関数Dの計算

次に、暗号化されたメッセージ13を復号化するための関数 D(13) を計算する D(13) = 133 mod 15

13^3 mod 15
≡ (-2)^3 mod 15 (∵ 13 ≡ -2 mod 15)
≡ -8 mod 15
≡ 7 mod 15

この計算の結果、 D(13) = 7 となる

D(E(7)) = 7 および E(D(y)) = y の関係が成り立つことが確認できた

Perlスクリプトを使うパターン

Perlスクリプトを読む

#!/usr/bin/perl
sub modpow {  #   b^e mod m
    my ($b, $e, $m) = @_;
    my $result = 1;
    while ($e > 0) {
       if (($e & 1) == 1) { $result = ($result * $b) % $m;  }
       $e >>= 1;
       $b = ($b * $b) % $m;
    }
    return $result;
}
print &modpow(@ARGV),"\n";

モジュラ指数計算(be mod m)を行うためのもの 具体的には、整数bのe乗をmで割った余りを計算する

暗号化関数Eの計算

スクリプトをmodpow.plとして保存して以下のコマンドを実行

$ perl modpow.w 7 11 15

コマンドの引数の7がb, 11がe, 15がmに対応し、7の11畳を15で割ったときの余りを計算する

$ perl modpow.pl 7 11 15

13

復号化関数Dの計算

$ perl modpow.pl 13 3 15

7

D(E(7)) = 7 および E(D(y)) = y の関係が成り立つことが確認できた

9.3 セキュリティ対策(2022年度)

このページの問題を解く


ツール

セキュリティ対策にはいろいろあるが、
   Web Service 
   個人のPC
   無線LAN基地局

などが対象になる。
Virus checker, log 監視ツール、システム管理ファイル監視システム などが、これらに対して、どのように有効か、有効でないかを考察せよ。
  • ウイルスチェッカー:
  • 個人のPCにおいては、ウイルスチェッカーは極めて重要である。これは、個人のPCが頻繁にインターネットを介して様々なリスクにさらされるため、マルウェアからシステムを保護する基本的な手段となる。 Webサービスの文脈では、ウイルスチェッカーは直接的な防御手段としては限定的であるが、ユーザーがアップロードするファイルをスキャンすることで二次的な防御線として機能する場合がある。 無線LAN基地局は、ウイルスチェッカーの対象とは一般的にならないが、管理システムにマルウェアが侵入することによるリスクを軽減するため、間接的な保護手段として利用できる。
  • ログ監視ツール:
  • 個人のPCでは、ログ監視は一般的な用途には用いられないが、セキュリティに精通したユーザーやIT専門家が問題の診断やインシデントの調査に用いることがある。 Webサービスにおいては、ログ監視ツールは非常に価値が高く、不正アクセスや異常なデータトラフィックパターンを検出する助けとなる。これにより、インシデント対応の速度と効率が向上する。 無線LAN基地局では、ログ監視は不審なアクティビティを識別し、セキュリティインシデントの早期発見に役立つ。
  • システム管理ファイル監視システム:
  • 個人のPCにおいては、一般ユーザーにとっては必要以上の機能であることが多いが、専門的な使用では重要な変更を追跡し、システムの安全性を維持するのに有効である。 Webサービスでは、この種の監視は不正アクセスや不正変更を迅速に検出する上で欠かせない。特に、構成ファイルやシステムファイルの無許可の変更を監視することは、サービスの安全性を確保するために重要である。 無線LAN基地局の文脈では、システム管理ファイルの監視は、ファームウェアの変更や不正な構成変更を検出するために、ある程度有効であるが、多くの場合、他のセキュリティメカニズムと組み合わせる必要がある。

PPAP

メールで資料を送る時に zip に password を付けて、別便でパスワードを送る方法がある。この方法がどうしてだめかを考察せよ。

PPAPとは、ZIPファイル送付と同じ経路でパスワードを自動で送るメールのやり取りの方式

P:Passwordつきzip暗号化ファイルを送ります
P:Passwordを送ります
A:Aん号化(暗号化)
P:Protocol

内閣府PPAPをファイルの送信方法として採用していたが、令和2年11月24日にPPAPを廃止すると平井内閣府特命担当大臣が発表した。(平井内閣府特命担当大臣記者会見要旨 令和2年11月24日)

  • 同じ経路を通るので同時に盗聴される危険性があり、無意味
    • 暗号化されてないのが原因
  • 暗号化されたzipファイルにウィルスが隠れている可能性がある(参考: Emotetの事例)
    • 送信されたデータの本人性を担保されてない、改ざんが行われていないことがわからない

よって「パスワード付きzipファイルじゃなくて、S/MIME暗号化して盗聴されても大丈夫なようにして、デジタル署名を付けて本人性と改ざんが行われていないことを証明すればいいじゃん。」みたいなことが書かれているといいと思う。


S/MIME

標準的な暗号化メールである S/MIME を使ってみよう
  1 S/MIME用の証明書(二重暗号鍵)を手に入れる (いろいろ方法はあるらしい)

           GMail はデフォルトであるかも

  2 それでサイン(署名)したメールを送る
       3  署名に公開鍵が入っているので、それで返信を暗号化して送信する

サイン付きのメールで課題を提出せよ

1 S/MIME用の証明書(二重暗号鍵)を手に入れる

  • 結論、actalisとthunderbirdを入れると楽で自己証明書でやろうとすると詰むかも、できた人すごい
  • Actalisで証明書を手に入れる
  • Apply for a free S/MIME certificate
    • メールアドレス(ドメインie.u-ryukyu.ac.jpのやつ)を入力して次へ
    • 確認コードがメールアドレスに送信されるのでそれをコピって貼り付け、利用規約的なやつのチェックボックスにチェックを付けてSubmit
    • 成功すると入力したメールアドレスに証明書が送られる、証明書のパスワードがwebページに表示されるのでメモる
    • メールを開いて、zipファイルをダウンロードして展開する
    • PKCS12_Credential_e205723@ie.u-ryukyu.ac.jp.pfxみたいなファイルが出てきたらOK

2 それでサイン(署名)したメールを送る

  • thunderbirdをダウンロードして開く
    • 学科メールアドレスでログイン→ Settings(歯車マーククリック) → Account Settings → End-To-End Encryption → Personal certificate for digital signing → Manage S/MIME Certificates → Your Certificates → Import... → PKCS12_Credential_e205723@ie.u-ryukyu.ac.jp.pfxを選択 → Personal certificate for digital signing の Selectボタンを押す → e205723@ie.u-ryukyu.ac.jp [Serial Number]を選択
  • Personal certificate for encryption も同じ証明書に設定しておく
  • InboxタブからWriteを選択すると、メールのドラフトが書ける、画面上にS/MIMEという項目があるので詳細を設定するために下ボタンをクリックして、Digitally Signにだけチェックを付ける
  • 課題の解答をメールを送信する
    • これでうまくいくかは知らないけど

3 署名に公開鍵が入っているので、それで返信を暗号化して送信する

kono先生から証明書付きのメールはもらったけど、どうやってimportするの...?

公開鍵が先生から直接添付で送られるようにしないとダメ説がある。

一応、「暗号化はなし、署名だけで課題提出OKですか」と聞いたら

そういうこと。そう書いてあるでしょ? 自分で鍵を生成あるいは取得して、それで署名して送る。

と言っていた。

よって、3はしなくてもいいらしい。


9.3 Side Channel Attack(2021年度)

このページの問題を解く

Side Channel Attach とは何かを100文字程度で説明せよ。

例示した Sice Channel Attach に対する対策を示せ。

Side Channel Attackとは

サイドチャネル攻撃とは、プログラムの欠陥を直接狙うのではなく、システムのプログラムを実行したときの処理時間やハードウェアの物理的な変化を観測して得られた情報から解析を行って暗号化されたデータを盗み取る攻撃である。Side Channel Attackの種類は情報の収集・解析方法によって多岐に分かれる。


対策

前述したと通り、Side Channel Attackには攻撃方法によって細かく種類が分かれるので、それぞれの攻撃方法によって対策の仕方が分かれる。今回はメッセージ長を用いるCompression Side Attackを取り上げて、対策を示す。Compression Side Attackは、圧縮が絡む処理で攻撃者が自分のデータを送信して秘密情報と一緒に圧縮して、圧縮の出力の長さから秘密情報の推測を行う攻撃手法である。

データ圧縮を行うとデータの冗長性を排除することである。LZ77という圧縮アルゴリズムを例に説明する。LZ77はデータに含まれる記号列が過去に出現したかどうかを調べ、出現していればその位置と長さの値で置き換えるアルゴリズムである。以下の文字列を圧縮する場合を考える。

「I thought what I’d do was, I’d pretend I was one of those deaf-mutes.」

この文字列には「I」、「'd」、「was」という文字列を複数含む。これらのような同じ文字列に相当するデータを1つだけ残して、そのコピーをどこに配置するかを示す指示を出力してLZ77はデータに圧縮を行う。

攻撃者のデータを「A」、推測したい暗号情報を「B」とし、AとBを一緒に圧縮したときにAとBに同じ部分があれば、データの圧縮が効くということになるので、圧縮の出力の長さからBを予測することができる。このようなBを予測する推測材料のことを圧縮オラクルと呼ぶ。

対策についてだが、TLS1.2の仕様[1]のSrction 6から引用して提示する。

Any protocol designed for use over TLS must be carefully designed to
deal with all possible attacks against it.  As a practical matter,
this means that the protocol designer must be aware of what security
properties TLS does and does not provide and cannot safely rely on
the latter.
Note in particular that type and length of a record are not protected
by encryption.  If this information is itself sensitive, application
designers may wish to take steps (padding, cover traffic) to minimize
information leakage.

Compression Side AttackはTLSプロトコルのレコードの型と長さが暗号化によって保護されない脆弱性を突いている攻撃だが、これはプロトコルの欠陥ではなく、プロトコルの限界である。仕様によれば、アプリケーションの設計者がパディングやトラフィック保護をすることで対策することを推奨されてる。

[1] The Transport Layer Security (TLS) Protocol, https://www.nic.ad.jp/ja/tech/ipa/RFC5246EN.html


9.3の感想

  • 攻撃と対策はイタチごっこになるみたいな話をよく聞くがこのレベルまで議論を深堀りしたら、そりゃイタチごっこになるわー...って思いました