🏕️

セキュリティ・キャンプのすすめ (2024 A 応募課題)

2024/08/29に公開

はじめに

pandaと申します。今回、選考を通過させていただき8/12-17にクロスウェーブ府中[1]で行われた「セキュリティ・キャンプ2024 全国大会」に参加してきました。少し出遅れた感はありますが、応募課題とその回答の公開が許可されているようなので自分の回答とそれぞれどのような意図で書いたのか、補足を付して記します。来年以降セキュリティ・キャンプに参加しようと考えている方の参考になれば幸いです。

きっかけ

以前から毎年Twitterで楽しげな様子が流れていたのでイベントの存在は知っていて、漠然と行きたいなあと思っていました。「応募しよう!」と思っては見送ることを繰り返していて、今年やっとその重い腰を上げて応募しました。(Twitterでとりあえずエントリーすることを勧めていた講師の皆さんありがとうございます)
このセキュリティ・キャンプの応募課題の少し前にSecHack365にも応募しており、ハードルが下がっていたということもあると思います。とにかく応募しましょう!

応募するコース選び

詳細は公式サイトを確認していただきたいのですが、セキュリティ・キャンプ2024は多くのクラス・ゼミがあります。過去回のことについてはあまり知らないのですが、今年はまず「専門コース」「開発コース」のどちらかを選び、その中で自分の興味があるものを専門コースは1つ、開発コースは第3希望まで選んでそれぞれに設定された応募課題に回答するという形でした。
私はとりあえず講義一覧のページを眺めて興味のあるものをいくつか絞り込み、最終的に全ての講義に興味があって多少は知識があったAコースを選択しました。(ほかにはC, S2, S5, S6, S8, S17, S18あたりにも興味がありました)
時間に余裕がある人は一旦興味のあるコース・ゼミの応募課題をそれぞれ見て解像度をあげるというのも参考になるかもしれません。(私は本当に時間がなくてA決め打ちでした...)

応募課題

適宜公式サイトを確認してください

問1

Q. 今年のセキュリティ・キャンプ全国大会に応募する理由を教えてください。また、Aクラスで受講したい講義(複数可)は何で、それぞれの講義でどのようなことを学びたいか、理由も含め教えてください。

私がこの大会に応募する理由は、まずセキュリティへの興味がある。全国大会ではその道のエキスパートから独学では得にくいようなセキュリティの知識を学ぶことができると考える。次に、同じセキュリティに興味のある人たちが集まることがある。応募課題を見てもかなり応募者のレベルは高いと感じられ、そういった環境の中で様々な課題を議論できるような友人を作りたい。最後に、全国大会の短期間に集中して講義を受けるというスタイルが私にとって楽しそうで魅力的に感じた。
共通の講義にも受講したいものがいくつもあり、Aクラスの全ての講義で自分の興味のある分野が含まれているので選ぶのは難しいが、特に受講したい講義はA5とA6である。前者は特に自動車業界のコーディングスタンダードというところに惹かれ、攻撃されると極めて危険となる車に搭載するプログラムの脆弱性をなくしていくためにどのようにセキュアコーディングを行っていくのか知りたい。きっと私が普段書いているコードとは違うものになるという気がしている。後者は私がCPUのアーキテクチャなどかなりの低レイヤの分野に興味を持つ要因ともなったMeltdownの問題について書いてあったのもあり、実際にCPUを論理ゲートで設計し、シミュレーションを行ったあとLSIの製造データを作成するところまで、一貫して行えるのはまさに自分がやってみたかったことであるため受講したい。この講義で作るCPUにはMeltdownの原因となった投機的実行などの高度な機能は盛り込めないと思うが、それでもCPU全体の動きを学ぶことができると考えている。また、電子回路からマスクに起こすのは実際の半導体の特性なども考慮しないといけないような気がして、独学では難しいことだと思うのでその工程もぜひやってみて学びたい。

何を考えながら書いたかとか

応募する理由

なぜ自分がこの「セキュリティ・キャンプ」に参加したいのか。特に、他にも多くあるイベントではなく、このイベントに参加したい理由を考えながら書きました。

受講したい講義

自分がAコースを選んだ決め手となった講義についてどこがどのように魅力的なのかを書きました。(回答にもあるように、Aコースは講義が全て魅力的だったので迷った記憶があります...)

問2

Q. 今までに作成したアプリ、プログラミング、電子工作、ブログやWebサイトなど、自分が中心になって設計や開発をしたものがあれば、それらの製作物やその応用について詳しく紹介してください(工夫した点などを自慢してください)。グループ開発の場合は、自分が行った範囲も明記してください。また、ブログ、GitHub、SNSのURLなど、製作物の内容や技術情報のまとめ等について公開しているものがあれば一緒に教えてください。

エピソードを多く書いたため自分や友人の個人情報が多々含まれています。そのまま公開することは難しいので概要をキーワードのように列挙しておきます。(規模だけ説明するとURL抜きで2800字程度書きました。)

  • ロボカップジュニアに友人とチームを組んで出場したこと
    • ルールの説明, プログラムを主に担当, 試行錯誤の過程, 工夫した点, 自慢
  • 高校の文化祭・運動会のホームページを作ったこと
    • 友人が大部分のHTML/CSSを作ってくれた, 画像を圧縮するなどのチューニングやアニメーションを主に担当, 少しJavaScriptのロジックの部分も書いた
  • 高校の文化祭でQRコードを用いた展示のスタンプラリーを作ったこと
    • コロナ禍の文化祭, 設計から実装まで全て自分でやった, Djangoで混雑状況を確認できるサーバーを作った, localStorageを使ってアカウント管理をしないで済むようにした
  • Arduinoでの電子工作
    • 高校の部活でたまに作っていたもの, 正体不明の部品を使うための試行錯誤, 制作での失敗

これに加えて応用情報技術者を持っていること、GitHub, Twitterのアカウントを記載しました。私のGitHubには何もありませんが、Private Repositoryを作って運用していました。その中でロボカップジュニアのものだけをダウンロードして、Google Driveにリンクを知っている人のみで共有し、そのリンクを貼っておきました。

何を考えながら書いたかとか

今見ればまだまだ書く内容がありますが、問にもあるようにとにかく今まで作ってきたもので人に見せることができるレベルにあるものを書きました。ここで欲が出て自分の力を盛って見せてしまいそうになりますが、自分はすぐボロが出ると思ったので自分のやったことだけを丁寧に書きました。
(Arduinoの電子工作は高校の部活において、学校公開日などで展示する必要があるときに、何もなかったために急いで作ったものも多く含まれており、こんなときに作った作品として書けるのラッキーだなあと思っていました。)

問3

Q. 脆弱性はソフトウェアの瑕疵や不具合が原因で、場合によっては人命を危険に晒し、社会インフラを停止させることがあります。

(1) どのようにしたら脆弱性をなくすことができると思いますか?

セキュアコーディング規則を意識して書くことで意図しないミスによる脆弱性を減らすことができるかもしれない。それでも、人間がコードを書く以上ミスによる脆弱性は無くならないため、メモリ安全性を言語で保証しているRustなどの言語を用いることで脆弱性を減らせるはずである。実際にAndroidの開発チームがC++からRustに書き換えたところメモリに関する脆弱性が大きく減ったということがあった。またiOSにあったインデントのミスによる重大な脆弱性を考えると、フォーマッタを用いてコードを読みやすく保つことも重要かもしれない。

何を考えながら書いたかとか

最初にこの問題を読んで思ったことは、人間が日々膨大なコードを書いている以上ある程度の脆弱性が生まれるのはしょうがないというものでしたが、どのようにすればなくすことができるのかということについてはあまり考えたことがありませんでした。そのため、過去に見た脆弱性関連の記事などを思い起こし、なるべく具体的な案を出すことに注力しました。

(2) あるいは無くすことができないとしたら、どのような対策を実施することで脆弱性によるこのような影響を低減できるでしょうか?

脆弱性は発覚した後、対応が遅くなればなるほど悪用される可能性が高くなる。よって、管理者であれば日常的にソフトウェアのアップデートの有無や脆弱性情報の確認を行い、対応策が出るまでの運用方法を考えることで脆弱性による悪影響を最低限に抑えられると考えられる。

何を考えながら書いたかとか

常に最新版のソフトウェアを利用することぐらいしか思いつきませんでした。
今読んで見れば、これは内製していないソフトウェアには有効な手段だと思いますが、自分たちで書いているソフトウェアに対する対策にはなっていないような気がしています。やはり、短時間では考えをつめきれずに、一般論を書くことしかできなかったように思います。プログラムの権限を適切に設定することなど、書けることはまだ多くありました。

(3) 突飛なアイデアでも構いませんので、まだ世の中にないと思われる対策のアイデアを自由に記述してください。

・コストがかかるが、全く同じ機能をもったソフトウェアを違う実装方法で2つ同時に開発して、どちらかに脆弱性が見つかったとき、パッチの適用を待たず瞬時に切り替えられるようにする。
・脆弱性は以前に見つかったものの派生のようなものも多いため、そのときどのように対策したのかをデータとして持っておいて、自動的にコードを書き換えて防御するAIの作成

何を考えながら書いたかとか

「まだ世の中にない」というところが重要ですが、0から考えることは難しいと思ったので、これまでの知識と結びつけながら有効な手段を考えようとしました。1つ目のアイデアはあまり関係ないように思えるかもしれませんが、Minecraftというゲームで公式のサーバープログラムの他にも独自の実装[2]が多くあることから思いつきました。2つ目のアイデアはLLMに「このコードを〇〇の方法で実装して」などと入力するとうまくいくことが多い印象で、脆弱性の対策というのはやるべきことが明確なものが多い気がするので(もちろんそのソフトウェアのロジック固有の部分などLLMには厳しいものも多くあると思いますが)、頑張ればできるんじゃね?といった感じで思いつきました。
しかし、この「まだ世の中にない」というところが非常に難しかったです。私がすぐに思いつくような対策が実行されていないのには理由があり、この他にも様々なアイデアを思いつきましたが、やらない理由があまりに明確すぎてほぼボツになりました。なんとか考えたこの2つの方法もいくらでも反論できると思います...(私も悲しいことに反論できます)

問4

Q. 以下の問いに、3つ以上答えてください。
あなたの熱意や得意分野の技量や実績が分かるように自由に記述してください。

(1) IoTデバイスは利用者に近いところに装置があり、直接または間接的に機器内部にアクセスが可能な場合があります。デバイス内やICチップに記録されたファームウェアや設定などからの秘密情報や技術の漏洩について、そのリスクと対策について述べてください。

「秘密情報や技術の漏洩」をどのように解釈するかによって答えも変わるが、ここでは個人情報の流出の話ではないと解釈して製品本体に秘匿されている情報の漏洩を考える。考えられるリスクを列挙し、耐タンパー性を向上させるための対策として考えられることを書く。リスクとしては、
① チップから直接ファームウェアや設定情報をダンプされ解析される
② ファームウェアを改ざんされ、秘匿したい情報を抜き取られる
③ インターネットとの通信を傍受され解析される。
④ ハードウェアに物理的に変更を加えられて想定外の動作を引き出し情報が取りだされる
といったものが挙げられる。具体的に①~④のことが行われるとデバイスに保存されているインターネットを含む認証情報(パスワードや鍵など)やプログラムの解析によって重要な技術が漏洩するため避けたい事態である。複合的に対策することが求められるが、①②はTPMなどの専用セキュリティチップを用いることでリスクを軽減でき、③は通信を適切に暗号化することでリスクを低減することができる。④はゲームコンソールのハッキングの歴史について調べるとわかるが、多種多様な攻撃方法があり、対策しにくい。(Xbox 360のハックではチップに穴を開けて制限を回避する方法もある!) OTAで修正できるような不具合であればすぐに更新をして、それが不可能な場合は早めに対策したバージョンをリリースするべきである (Nintendo Switchの初期の本体には修正できない脆弱性があり発売後1年程度で対策版に置き換わったという例がある)

何を考えながら書いたかとか

最初よく設問の意図を汲み取れずよくわからないことを書いていた記憶があります。なんとか立て直して、ここでは意図しない方法(パスワードを盗まれて正攻法で突破されるなどは考えない)を用いて情報が盗まれることだろうと解釈して記述しています。この設問は私が以前から興味を持っていたPCのSecurebootや、iPhoneなどのjailbreak手法、ゲームソフト/ゲーム機の解析を読んでいたため、そのあたりのことを持ってきて書きました。
(この設問からおそらく深夜の睡魔との戦いが始まっています...文章を読み解いてくださりありがとうございました。)

(2) 自由に半導体チップを設計・製造できるとしたら、どんなチップを作ってみたいですか?「自分が/技術的に可能かどうか」は気にせずに、夢を語ってください。

常用できる性能を備えたうえで性能/消費電力を極限まで追い詰めたチップを作りスマホやウェアラブル端末に搭載したい。そのためにはコアの設計(デコーダーやALUの数や分岐予測の回路など)を大きくし、キャッシュを増やし、コア数を増加させることで周波数を上げないことが重要になる。一般向けのチップだとダイサイズを抑えないと1枚のウェハーからとれるチップの数量、歩留まりが低下するのでこういった設計は敬遠されがちであるが、それらを無視した夢のチップを作りたい。

何を考えながら書いたかとか

かなりの半導体オタクなのでこの設問を考えるのはとても楽しかったです。しかし、奇をてらった「夢のチップ」というものは、処理内容、製造方法ともにこれまでの流れや、これからどのように半導体が進化していくのかを表すロードマップにとらわれてしまいなかなか思い浮かびませんでした。結局自分の好きなCPUの話、特にApple Silicon (M1-)で推し進められているコアの設計の巨大化の話をして、それを夢としました。[3]

(3) 低レイヤ(製品、デバイス、CPU、OS、プログラミング言語、Ethernet/Wi-FiやTCP/IPネットワークなど)について、自分が好きなアーキテクチャや仕様についてどこが良いかを説明してみてください。そして、それをさらに良くする(自分の好みにする)にはどうしたいかも教えてください。

私はヘテロジニアスマルチコア(同一ISAのプロセッサではあるが違うコアを備えるものも含む)の考え方が好きでクロック数やIPC向上に陰りが見えてきたこの先も発展していく兆しがあるという点で良いものであると考える。もともとベクトルプロセッサやGPGPUといったアクセラレーターによって特定の計算を汎用プロセッサであるCPUで行うよりも効率よく処理できるという考え方が好きであったが、CPUで求められる処理は色々あるのにいつまでもコアを大きくするor同じコアを増やしていくことしか行われてこなかった。PS3のCellにもこの考え方が採用されたこともあるし、もしかするとこれ以前にもこの考え方があったかもしれないが、私が思うにモバイルにはArmのbig.LITTLEを採用したSnapdragon 810から、デスクトップ/ノートPCにはAlder Lakeから普及し始めたように思う。このコンセプトの良いところは同じCPUでもシングルスレッドでの処理速度を要求する操作とマルチスレッドで並列して処理できる操作を分けてより合ったコアで実行することで電力効率やダイ上での面積効率を増加させることにある。これにより限られた電力やダイサイズの中でよりよいパフォーマンスを引き出すことに成功している。
このコンセプトを発展させるアイデアとして私が考えるのはSMTの考え方を発展させてCPUの巨大な演算器やキャッシュを流動的にコアに割り当てて使えるようにして(可能かどうかはわからないが)例えばAVX512を処理するような大きな演算器が何もしない時間を減らし全ての演算器をフル活用するような設計にすることである。こうすれば例えば今のintelのCPUのEコアにAVX512を処理できるような演算器が乗っていないためPコアにあるAVX512を丸ごと無効化するといったことが起こらなくなるはずである。

何を考えながら書いたかとか

どこが良いかを説明してみてください。

まず何を書くかかなり迷いましたが、ここ数年興味があったことについて書きました。設問通り良いところを理解してもらうためにこのCPUの中では変わったアーキテクチャがなぜ登場することになったのか、なぜ素晴らしいのかについて語りました(Alder Lakeの前にLakefieldがありますが普及はしていなかった気がするのでここでは書きませんでした)。

どうしたいかも教えてください。

これもかなり迷って、CPUのスケジューリング調整について書こうとしていました。というのもヘテロジニアスマルチコアはOSレベルでのスケジューリングが非常に重要で、このスケジューリングを間違えると体感の処理速度が低下してしまったり、余分な電力を消費してしまったりすることになるからです。しかし、これは今取り組まれていることで面白みがないのでこのスケジューリングを楽にする方法について考えてそれを書きました。終わってみれば、ここで書いたものの方実現可能性的に夢のチップに近いような気がします。

(4) あなたが過去に設計開発したプログラムのうち、セキュアコーディングを意識して実装したコード例を1つ挙げて、どういった攻撃に対して防げるのか説明してください。

これがセキュアコーディングかどうかはわからないが、攻撃に耐える設計を作ろうと思ったことがある。QRコードのスタンプラリー(前述)の混雑状況を測定する機能を実装するときに、来場者1人1人に対してID認証ができれば一番だったのだがそれはできなかったため、スタンプラリーを始めるときに一度開始する専用のQRコードを読んでもらってそこでその端末に擬似的なIDを付与し、スタンプを取得するQRコードを読んだときにその疑似IDが存在し、スタンプを始めて取得するときだけサーバーに疑似IDとともに送るようにした。サーバー側ではそのIDとUAを確認し、なんとかそのURLをリロードされ続けても混雑状況が異常な値を示さないようにした。本番の日攻撃されるようなことはなかった。

何を考えながら書いたかとか

普段はあまりインターネットに公開するようなプログラムのコードは書かないので特別に意識することは少ないのですが、このスタンプラリーを作るときはかなり考えて作ったため、そのときのことを書きました。文化祭直前に実装したため期間がかなり短く、実際に悪意を持った攻撃者に解析されると混雑状況が正常に表示できなくなっていたと思います。(メインはQRコードのスタンプラリーだから、攻撃受けたら混雑状況は削除しようかな、使えなくてもいいか、ぐらいの気持ちでいました)
どういった攻撃を防ぐことができるのか書いた文は少しわかりにくいですが、言っていることは各QRコードを連続で読み込まれたときに混雑状況を更新し続けることがないようにしたということです。

(5) 過去にTCP/IPやEthernet/Wi-Fi/Bluetoothに関するプログラミングやパケット解析の経験があれば、具体的に教えてください(どんなツールを使って、なぜそれを使ったのか。経験から気づいたことなど)。

定番のWireSharkでNASの起動方法を探った。私の家にはBuffaloのNASがあるが、そのNASを起動するためにはBuffaloのソフトウェアをインストールしサービスを起動しなければならなかった。そのサービスが起動している間はずっとNASが起動したままであるためサービスのオン・オフを切り替えることや、そもそもそのソフトウェアをインストールするのが面倒だったため、どういった処理でNASが私のPCの起動状況を確認しているのかパケット解析を行った。その結果はただ定期的にWOLを3回続けてNASに送信しているだけ(その間隔は回線がパンクすることを恐れてか毎回違った)であり、NASは5分間WOLのパケットを受け取らなかった場合にシャットダウンするという挙動を示した。少しWOLの使用目的からは離れているのではないかと疑問に思うところはあったが別のWOLのマジックパケットを送ることができるソフトを使うことでより柔軟に起動状態を制御できるようになった。
他にもESP32で温度ロガーを作りその温度をPHPで動く自宅サーバーに送信するものを作ったり、LAN内で写真を転送するアプリを制作した。最近はLANDropというLAN内でファイルを共有できるソフトについてパケットを解析している。

何を考えながら書いたかとか

解析としては少し簡単すぎたため、もっと骨のある解析を行ってこなかったこと、もう解析するには時間が足りないことを後悔しましたが、以前に行ったNASの解析について具体的に書きました。この課題を読んでから気になっているプログラムの解析も始めました。(わからないことがあって放置中...)

(6) コネクティッドな(ネットにつながる)家電製品や車において、考えられる攻撃シナリオ、セキュリティリスクとその対策について例を挙げながら考察してみてください。

家電製品で一番怖いものは冷蔵庫やエアコン、ヒーターといった私達に直接関わるもので、例えば冷蔵庫だと自分たちがいない間に勝手に温度を上げて腐らせたあとまた冷やしてそれに気づかないといったことや、エアコン、ヒーターだと寝ているときにいきなり気温を上昇させられて熱中症になるといったことが考えられる。車が乗っとられると操作を効かなくさせらたりいきなり速度を上げさせられたりして自分たちの生死に関わるので特に慎重にならなければならないと思う。

何を考えながら書いたかとか

この設問までたどり着いたとき、23:45辺りになっていた記憶があります。攻撃シナリオは考えることができましたが、その対策については時間がありませんでした...

改善点

回答を書き終えた(要出典)直後は達成感ばかりでしたが、やはり書き残したことは多く、推敲もしっかりと行うべきでした。また、完全に失念していたような気がしますが、選考のポイントぐらいは確認しておくことをおすすめします。
IPA公式サイトより
この回答は時間の都合上、ほぼ今までの知識だけで構成されていますが、おそらくこの課題に取り組むときにインターネットや書籍などで調べて新たな情報を入れながらor手を動かしながら書いたほうが良いものになると思います。

おわりに

この課題を書いているときはあまり意識していなかったのですが、各設問にそれぞれの講師の方の特色が出ている気がしました。終わってみて考えると、各講義に期待していたことの多くは満たされ、むしろ予期していなかった学びも非常に多かったです。本当に有意義な期間でした。

私はこの応募課題をWordで書きましたが、久しぶりに開こうとすると応募課題締め切りが5/20 23:59のところ、最終編集日時が "5/20 23:57" でした(OneDriveの履歴を見ると5/20 00:00の時点では数十字しか書いていませんでした)。その日は大学もあり、我ながら本当によくやったと思います。

また、この応募課題を書いたあと他の応募課題も確認しましたが、多くの課題で問題が出されてそれを解く形式になっていて、始めた時点で24時間を切っていた自分が回答を完成させられたのは問題がなかったAクラスを選んだからだったのかな?などと少し怖い思いもしました。非常に興味深い問題が多く、ぱっと見て手も足も出ないように見えるものも多くありましたが、いくつかは検索して途中まで解いてみたり、実際に他クラスの友人と話したりして楽しませていただきました。実際に手を付けていない問題もありますが、面白かった(そう)な問題をいくつか書いておきます。

面白かった(そう)問題
  • C 問6
    • ファイルシステムやinodeの構造などよくわかっていないところを調べるきっかけになって面白かった。マウントして取り出せたときが嬉しかった。
  • S02 問1
    • x86-64では主にIntelとAMDが作ってきた命令セットを使ってきたが、RISC-Vでは独自命令を追加できるというのは今までに考えたこがなく非常に面白かった。私は、x86-64にあるPEXT命令を思い出した。将棋の探索プログラムで使われていたことで知った命令[4]であるが、非常に複雑な処理をしているのに非常に軽量で(Zen2ではucode実装になっていたが...)回路で実現できることの奥深さを知ることができた。
  • S05 問3
  • S06 問6
  • S13 問4
  • S18 C

イベント期間は慢性的な睡眠不足でしたが講義や交流が非常に楽しくドーパミンでなんとかなりました。応募課題にも書いたように同じセキュリティに興味をもつ人はもちろん幅広い分野に興味を持ち、技術力を兼ね備えた友達をつくることができ、これからより一層開発に力をいれるモチベーション向上にもつながった気がしています。

応募しない限り通る確率は0なのでとにかく応募しましょう!!!

脚注
  1. クロスウェーブ府中は2024年8月末をもって閉館するそうなので、ここで行われた最後のセキュリティ・キャンプということになります(!)。 ↩︎

  2. 公式サーバーのmodも多いが、完全にMojangのコードを使わずに開発されているものもある。 ↩︎

  3. この回答の直後に、少し前に発売されたApple M4の解析が出てきて、M3と比較してどうやらここで書いた夢のチップのような進化を遂げているようでした。(Eコアの増加 4→6、デコーダーの増加 9→10 etc.)(出典) この方向を更に進めていくことで夢に近づきますが、書いた案が少し現実的すぎた気もしました。(厳密に言えばM4とここで書いたチップではスケジューリングの考え方が異なっています。) ↩︎

  4. やねうら王作者による解説 ↩︎

Discussion