=======================
AESに関するポリシー(仮)
=======================

現在のライブラリ実装は自由に扱える状態だが、最終的には
以下のポリシーを反映した形に制限を加える。


○(予習)鍵の種類

次の4組の鍵の組み合わせが存在する。

    KEY[0]	ID[0]		SEED[0]
    KEY[1]	ID[1]		SEED[1]
    KEY[2]	ID[2]		SEED[2]
    KEY[3]	ID[3]		SEED[3]

○(予習)鍵の基本事項

それぞれが独立したレジスタであるが、SEEDを設定したときに、

	SEED + ID => KEY

という計算処理がおこなれる(計算式は秘密)。

また、任意のタイミングでKEYのひとつをAESコアに送ることができる。
このAESコアに送る作業を行わない限りAESで使用される鍵は
変更されない。

○(予習)種別ごとの意味合い

KEYは一般的なAES回路として他のシステムとやり取りするような
データを取り扱うときにのみ使用する。

IDとSEEDは任天堂依存のやりとりで使うことになるが、
基本的にIDの方はシステム側であらかじめ設定しておき、
アプリケーションには操作させない。


●IDによるそれぞれの鍵の方針

        デバイス依存	アプリケーション依存
	(ユニークID)	(イニシャルコード)
    0:      ×                   ○
    1:      ○                   ○
    2:      ×                   ×
    3:      ○                   ×

ここで、デバイス依存とは、eFuseの内容を反映するということ。
また、アプリケーション依存とは、ROMヘッダ辺りを反映するということ。

上記の内容を反映するように、IDを設定することになる。
ただし、KEYを直接設定する場合は、この意味合いは関係ない。


●アプリケーションが触ることのできる部分

アプリケーションには、KEY[2]、SEED[0]〜SEED[3]を使えるようにする。
とりあえずは、SEED[2]は解放しない。


●ARM7側初期化コード

ROMコードで全レジスタの初期値を設定している。
大半はダミーだが、ID関係の固定値はここでのみの設定となる。

アプリケーションローダー用に、TwlFirm内にIDのgame_code依存
部分のみを再設定するコードを用意している。

アプリケーション起動後はIDを触ることは無い。


●ARM9側API

次のような個別のAPIを用意してみた。

AES_SetGeneralKey()		KEY[2]に鍵を設定する
AES_SetSystemKey()		SEED[3]に鍵を設定する
AES_SetGameKey()		SEED[0]に鍵を設定する
AES_SetSpecialKey()		SEED[1]に鍵を設定する
//AESi_SetAlternativeKey()	SEED[2]に鍵を設定する (非公開)

それぞれ引数をすぐに有効にするもので、「以前の鍵」という使い方は
(とりあえず)できないようにしている。

課題: Static領域の読み直しはさせないのか？
	(.data領域は最低必要かと思われるが・・・)
	(少なくとも0の)SEEDは設定できないようにしてしまうか。

●ARM7側API

個別に指定することも上記APIを使用することもできる。
個別設定用に、次のenumを用意している。

typedef enum
{
    AES_KEYSEL_GAME         = 0,
    AES_KEYSEL_SPECIAL      = 1,
    AES_KEYSEL_ALTERNATIVE  = 2,
    AES_KEYSEL_SYSTEM       = 3,

    AES_KEYSEL_IPL          = AES_KEYSEL_ALTERNATIVE,

    AES_KEYSEL_GENERAL      = 2 // for key register
}
AESKeySel;