https://www.fe-siken.com/kakomon/22_aki/pm04.htmlの情報セキュリティです。
今、過去問をアウトプットの意味合いで完全網羅している途中です。この回の問題が解説をみても全然
理解できずとても困っています。丸投げになってしまって申し訳ございませんが、この問題の空欄
a,b,c,d全てを教えてください。お願いします。

この投稿は投稿者により削除されました。(2021.07.19 08:18)

まず暗号鍵ってのは他人に分かられちゃ困るわけです。AESとかみたいな共有鍵の場合はなおさら。この辺がマジでわからん、となる場合は参考書とかそういうサイトとかを読むところから始めないと話が進まなくなると思うので真剣にそういうのを読まないと  ダメ  です。問題を解くとかそういう次元にない。

で、利用者IDなんかはふつうにどっからでも見えます。ブラウザのF12でhiddenとかにはいってるかもしれませんよ。Cookieとか覗いたら入ってるとかありますからねえ。そんなもんを鍵には使えない。
チケット発行サーバのIDだと、これもまた予測されやすい。そんなランダムな値でやってたら開発側が大変だし、だいたい危胎化（鍵がバレた）したってしょっちゅうそんなもんを変えられないじゃないか。
セッション鍵の場合、セッション（ユーザからのHTTPリクエストがサーバに飛んできて、レスポンスを返したらコネクションが死んでしまうから、アマゾンとかみたいな何回もそれをユーザ情報を保持しながら繰り返さなきゃいけないとこは、クライアントとサーバー間でその情報を保持し、アクセス制御を一つの集合体として管理する仕組みが必要となり、この仕組みをセッション管理という）が発生する（Cookieを発行する）たびにランダムな値で（そらそうで、予測できたらセッションハイジャックできちゃうから）Cookieを発行するわけですよ。そんな使い捨てのをサーバに残しとかないし、そもそも鍵DBにそんなもんを登録してないからDBもなんのことっすか？状態になって話にならないので、やはりこれもサーバ内データの暗号鍵には使えない。というわけで腹がかえしている、鍵DBにもってるチケット発行サーバTの鍵KEY_Tです。まあ、これは4択だからこんな書き方してますけど、ダイレクトに聞かれたらサーバ内で自前で抱えてる鍵って反応できないと今後がまずい。

次はbとc
で、enc（TICKET_CT）の結果が復号された（平文の）KEY_CTなわけで、これをどう使おうっつったらクライアントとチケット発行サーバとの通信のセッション鍵って表にありますから、もうまんまbはC-T間のセッション鍵KEY_CTですよ。
で、cはチケット発行サーバからクライアントへの通信で、最終目的のAPサーバへの通信の手前な訳ですが、
当然APサーバはAPサーバの暗号鍵しか持ってないから、チケット発行サーバとかと使い回しなんかしてませんから、それに適用したフォーマットにしといてやらなきゃいけない。要は、APサーバの暗号鍵で暗号化したやつを送ってきたら復号できるからよ、ってことですよ。クライアントがAPサーバの暗号鍵なんか持ってるわけがないから、チケット発行サーバ側で、APサーバの暗号鍵で暗号化したTICKET_CSをクライアントに投げてそれをまた丸投げしてやるわけです。というわけで答えはAPサーバSの鍵KEY_S。

dは認証子AUTH_C2をどう暗号化しようかね、って話ですけど、APサーバとクライアントしかわかられちゃ困るってことは、もうCS間のセッション鍵しかねえよな、ってわけです。通信を使い捨てのセッションで暗号化したら用済みなんだから。
APサーバSでは「enc(TICKET_CS)」、つまりチケット発行サーバがAPサーバの鍵で暗号化されたやつを投げつけられたら自前の鍵「KEY_S」で復号して、この平文ってのは表にあるようにC-S間のセッション鍵で、
レスポンスでこのセッション鍵を返したら、APサーバとのクライアント側でこの「KEY_CS」を使って暗号化してから送信することで、CS間の暗号化通信ができるよねって話ですよ。だから答えはC－S間のセッション鍵KEY_CSになる。

ありがとうございます！！
今までは自分の勝手な思い込みで問題を解いていましたが、GinSanaさんの分かりやすい解説と一緒に問題をといていたら自然と自分自身も一人で解けるようになりました。とっても嬉しいです。