Virtualisasi Sumber Daya

Fungsi utama TBS adalah berbagi sumber daya TPM terbatas tertentu secara efisien: kunci, otorisasi, dan sesi transportasi.

Ketika instans salah satu sumber daya ini dibuat, TBS membuat instans virtual sumber daya, dan mengembalikan handel ke instans virtual ini dalam aliran perintah hasil (daripada instans handel aktual yang dikembalikan oleh TPM). TBS mempertahankan pemetaan antara handel virtual dan handel aktual secara internal. Jika TPM kehabisan ruang untuk menyimpan lebih banyak sumber daya dari jenis tertentu, instans sumber daya yang ada disimpan secara selektif dan dikeluarkan hingga TPM dapat menyimpan sumber daya baru. Ketika sumber daya lama diperlukan lagi, TBS memuat konteks yang disimpan (menyimpan dan membuang sumber daya lain jika perlu) sebelum mengirimkan perintah.

Semua virtualisasi dalam TBS dilakukan atas nama konteks tertentu. Setiap konteks hanya diizinkan untuk mengakses sumber daya virtual yang dibuat khusus atas namanya, serta sumber daya fisik pada TPM yang sesuai dengan sumber daya virtual tersebut. Secara default, jumlah total semua sumber daya virtual dibatasi hingga 500. Jumlah ini dapat diubah dengan membuat atau memodifikasi nilai registri DWORD bernama MaxResources di bawah HKEY_LOCAL_MACHINE\Software\Microsoft\Tpm. Penggunaan sumber daya TBS real time dapat diamati dengan menggunakan alat Monitor Performa untuk melacak jumlah sumber daya TBS. Pembatasan ini menjadi usang dengan Windows 8 dan Windows Server 2012.

Sumber daya TPM terbatas yang tidak divirtualisasi oleh TBS (seperti penghitung dan penyimpanan NV) harus dibagikan secara kooperatif di antara tumpukan perangkat lunak.

Batas Sumber Daya

TPM memungkinkan penelepon untuk mengkueri kemampuannya untuk menentukan berapa banyak ruang yang tersedia untuk jenis sumber daya tertentu. Beberapa batas sumber daya ini, seperti jumlah ruang yang tersedia untuk kunci, sesi otorisasi, dan sesi transportasi, secara efektif diperluas oleh TBS melalui virtualisasi. Batasan TBS, yang dikontrol oleh pengaturan registri MaxResources, biasanya jauh lebih besar dari batasan aktual perangkat keras TPM yang mendasar. Tidak ada mekanisme yang disediakan untuk mengkueri batasan TBS secara terpisah dari batas perangkat keras TPM. Batasan TBS ini menjadi usang dengan Windows 8 dan Windows Server 2012.

Tombol

TBS memvirtualisasi handel kunci sehingga kunci dapat dibongkar secara transparan dari TPM ketika tidak digunakan dan dimuat kembali ke TPM saat diperlukan. Saat kunci dibuat, TBS mengaitkan handel virtual dengan kunci yang dimuat. Handel virtual yang sama digunakan untuk masa pakai sumber daya. Handel kunci virtual hanya valid dalam konteks yang membuatnya, dan sumber daya terkait tidak dipertahankan di luar masa pakai konteks.

• Membuat Kunci dengan TPM_LoadKey2

  Jika kunci dibuat dengan menggunakan perintah TPM_LoadKey2, TPM2_CreatePrimary, TPM2_Load, atau TPM2_LoadExternal, TBS mengganti handel dalam aliran byte pengembalian dengan handel kunci virtual yang dipilihnya. Akibatnya, TBS memastikan bahwa setiap handel virtual unik. Jika TBS mendeteksi tabrakan (peristiwa yang sangat tidak mungkin), TBS akan membongkar kunci dari TPM dan menginformasikan perangkat lunak panggilan. Perangkat lunak kemudian dapat mengirim ulang operasi. Proses ini dapat diulang sampai TBS mendapatkan handel kunci yang unik.

• Menghapus Kunci

  TBS membatalkan handel kunci virtual saat menerima pesan TPM_FlushSpecific atau TPM2_FlushContext untuk handel virtual tersebut dari konteks klien. Jika kunci secara fisik ada di TPM saat pesan flush diterima, TBS akan menghapus kunci dari TPM pada saat itu.

• Menghapus Kunci Untuk Sementara

  Saat mengusir kunci dari TPM untuk memberi ruang bagi item baru, TBS menjalankan perintah TPM_SaveContext atau TPM2_ContextSave pada kunci sebelum mengusirnya.

• Memulihkan Kunci

  Ketika perintah yang mereferensikan kunci yang dimuat dikirimkan ke TBS, perintah tersebut memastikan bahwa kunci ada secara fisik pada TPM. Jika kunci tidak ada, TBS memulihkannya dengan panggilan ke TPM_LoadContext atau TPM2_ContextLoad. Jika kunci tidak dapat dipulihkan ke TPM, TBS mengembalikan TPM_E_INVALID_KEYHANDLE sebagai hasil TPM.

TBS menggantikan setiap handel virtual yang terkait dengan kunci dalam aliran perintah dengan handel fisik kunci yang dimuat pada TPM. Jika perintah dikirimkan dengan handel virtual yang tidak dikenali oleh TBS dalam konteks pemanggil, TBS memformat aliran kesalahan untuk pemanggil dengan TPM_E_INVALID_KEYHANDLE.

Sesi Otorisasi

Sesi otorisasi dibuat dengan memanggil TPM_OIAP, TPM_OSAP, atau TPM_DSAP. Dalam setiap kasus, aliran byte pengembalian berisi handel TPM fisik dari sesi otorisasi yang baru dibuat. TBS mengganti ini dengan handel virtual. Ketika sesi otorisasi kemudian direferensikan, TBS mengganti handel virtual di aliran perintah dengan handel fisik sesi otorisasi. TBS memastikan bahwa masa pakai sesi otorisasi virtual cocok dengan sesi otorisasi fisik. Jika klien mencoba menggunakan handel virtual yang kedaluwarsa, TBS memformat aliran kesalahan dengan kesalahan TPM_INVALIDAUTHHANDLE.

Slot sesi terbatas, dan TBS dapat kehabisan slot eksternal untuk menyimpan konteks sesi otorisasi. Jika ini terjadi, TBS memilih sesi otorisasi untuk membatalkan validasi sehingga konteks baru dapat berhasil disimpan. Aplikasi yang mencoba menggunakan konteks lama perlu membuat ulang sesi otorisasi.

TBS membatalkan sesi otorisasi virtual ketika salah satu kasus berikut terjadi:

• Bendera lanjutkan penggunaan yang terkait dengan sesi otorisasi dalam aliran perintah yang dikembalikan dari TPM FALSE.

• Perintah yang menggunakan sesi otorisasi gagal.

• Perintah dijalankan yang membatalkan sesi otorisasi yang terkait dengan perintah (seperti TPM_CreateWrapKey).

• Kunci yang terkait dengan sesi OSAP atau DSAP dikeluarkan dari TPM dengan panggilan ke TPM_FlushSpecific atau TPM2_FlushContext (tanpa memperhatikan apakah perintah ini berasal dari TBS atau dengan perangkat lunak tingkat yang lebih tinggi).

  TBS akan secara otomatis menyinkronkan ulang sesi otorisasi setelah berhasil menjalankan perintah nondeterministik tertentu untuk memastikan bahwa status TBS tetap konsisten dengan status TPM. Perintah yang terpengaruh adalah:

  • TPM_ORD_Delegate_Manage
  • TPM_ORD_Delegate_CreateOwnerDelegation
  • TPM_ORD_Delegate_LoadOwnerDelegation

Dalam setiap kasus berikut, sesi otorisasi pada TPM dihapus secara otomatis oleh TPM:

• Membuat Sesi Otorisasi

  Handel sesi otorisasi virtual hanya valid dalam konteks yang membuatnya, dan sumber daya terkait tidak dipertahankan di luar masa pakai konteks terkait.

• Menghapus Sesi Otorisasi

  TBS membatalkan sesi otorisasi virtual jika menerima perintah TPM_FlushSpecific atau TPM2_FlushContext untuk handel virtual dari konteks klien. Jika sesi otorisasi secara fisik ada di TPM saat perintah flush diterima, TBS akan segera menghapus sesi fisik dari TPM.

• Menghapus Sementara Sesi Otorisasi

  Saat mengusir sesi otorisasi dari TPM untuk memberi ruang bagi entitas baru, TBS menjalankan TPM_SaveContext atau TPM2_ContextSave pada sesi otorisasi tersebut.

• Memulihkan Sesi Otorisasi

  Ketika perintah TPM resmi dikirimkan ke TBS, TBS memastikan bahwa semua sesi otorisasi virtual yang dimaksud dalam perintah secara fisik ada di TPM. Jika salah satu sesi otorisasi tidak ada, TBS memulihkannya dengan panggilan ke TPM_LoadContext atau TPM2_ContextLoad. Jika sesi otorisasi tidak dapat dipulihkan ke TPM, TBS mengembalikan TPM_E_INVALID_HANDLE sebagai hasil TPM.

TBS menggantikan setiap handel virtual yang terkait dengan sesi otorisasi dalam aliran perintah dengan handel fisik sesi otorisasi yang dimuat pada TPM.

Jika perintah dikirimkan dengan handel virtual yang tidak dikenali oleh TBS dalam konteks pemanggil, TBS memformat aliran kesalahan untuk pemanggil dengan kesalahan TPM_E_INVALID_HANDLE.

Sesi Transportasi

Sesi transportasi adalah mekanisme yang disediakan oleh TPM yang memungkinkan tumpukan perangkat lunak untuk mengenkripsi data dalam perintah saat melewati antara perangkat lunak dan TPM. Ini mencegah seterusnya mencegat data saat melewati bus perangkat keras.

Sayangnya, mekanisme ini juga mencegah TBS memeriksa data payload. Dalam kebanyakan kasus, ini bukan masalah karena TBS hanya memodifikasi handel, bukan data payload. Namun, dalam kasus TPM_LoadContext misalnya, handel sumber daya yang dikembalikan dicakup oleh enkripsi. Oleh karena itu, TBS mencegah upaya untuk melakukan operasi TPM_LoadContext yang dicakup oleh sesi transportasi.

TBS memblokir perintah berikut di bawah sesi transportasi:

• TPM_EstablishTransport
• TPM_ExecuteTransport
• TPM_Terminate_Handle
• TPM_LoadKey
• TPM_EvictKey
• TPM_SaveKeyContext
• TPM_LoadKeyContext
• TPM_SaveAuthContext
• TPM_LoadAuthContext
• TPM_SaveContext
• TPM_LoadContext
• TPM_FlushSpecific

Ketika salah satu perintah ini dicakup oleh sesi transportasi, TBS mengembalikan TPM_E_EMBEDDED_COMMAND_UNSUPPORTED sebagai hasil TPM.

Handel sesi transportasi divirtualisasi dengan cara yang mirip dengan handel kunci dan handel otorisasi. Ada sejumlah slot konteks sesi transportasi tersimpan yang tersedia di TPM.

TBS membatalkan sesi transportasi virtual jika salah satu kasus berikut terjadi:

• Bendera lanjutkan penggunaan yang terkait dengan sesi transportasi dalam aliran perintah pengembalian dari TPM FALSE.

  Seperti halnya sesi otorisasi di atas, TBS akan secara otomatis menyinkronkan ulang sesi transportasi setelah berhasil menjalankan perintah nondeterministik tertentu untuk memastikan bahwa status TBS tetap konsisten dengan status TPM. Perintah yang terpengaruh adalah:

  • TPM_ORD_Delegate_Manage
  • TPM_ORD_Delegate_CreateOwnerDelegation
  • TPM_ORD_Delegate_LoadOwnerDelegation

Dalam setiap kasus ini, sesi transportasi pada TPM akan dihapus secara otomatis oleh TPM:

• Membuat Sesi Transportasi

  TBS membuat handel virtual untuk setiap sesi transportasi yang dibuat oleh klien. Handel transportasi virtual hanya valid dalam konteks yang membuatnya, dan sumber daya terkait tidak dipertahankan di luar masa pakai konteks terkait.

• Menghapus Sesi Transportasi

  TBS membatalkan sesi transportasi virtual jika menerima perintah TPM_FlushSpecific untuk handel virtual dari konteks klien. Jika sesi transportasi secara fisik ada pada TPM ketika perintah flush diterima, TBS akan segera menghapus sesi fisik dari TPM.

• Menghapus Sementara Sesi Transportasi

  Saat mengusir sesi transportasi dari TPM untuk memberi ruang bagi entitas baru, TBS menjalankan TPM_SaveContext pada sesi transportasi tersebut.

• Memulihkan Sesi Transportasi

  Ketika perintah TPM_ExecuteTransport dikirimkan ke TBS, TBS memastikan bahwa sesi transportasi yang dimaksud dalam perintah secara fisik ada di TPM. Jika sesi transportasi tidak ada, TBS memulihkannya dengan panggilan ke TPM_LoadContext.

TBS menggantikan handel virtual yang terkait dengan sesi transportasi dalam aliran perintah dengan handel fisik sesi transportasi yang dimuat pada TPM. Jika perintah dikirimkan dengan handel virtual yang tidak dikenali oleh TBS dalam konteks pemanggil, TBS memformat aliran kesalahan untuk pemanggil dengan menggunakan TPM_E_INVALID_HANDLE.

Sesi Transportasi Eksklusif

Sesi transportasi yang dibungkus eksklusif adalah cara bagi perangkat lunak tingkat atas untuk menentukan apakah perangkat lunak lain telah mengakses TPM selama rantai perintah. Mereka tidak mencegah perangkat lunak lain mengakses TPM, mereka hanya memberi pembuat sesi transportasi sarana untuk menentukan bahwa beberapa akses lain terjadi. TBS tidak melakukan sesuatu yang spesifik untuk menghambat sesi transportasi eksklusif, tetapi agak tidak kompatibel dengan mereka. TBS mencoba menduplikasi perilaku alami TPM dengan bersikap transparan, sehingga tidak mendukung perintah dari konteks yang menetapkan sesi transportasi eksklusif. Misalnya, jika klien B mengirimkan perintah ketika klien A berada dalam sesi transportasi eksklusif, maka itu akan membatalkan sesi transportasi eksklusif klien A.

Perintah yang dimulai oleh TBS juga dapat mengakhiri sesi transportasi eksklusif. Ini terjadi ketika klien A berada dalam sesi transportasi eksklusif, dan perintah yang dijalankan oleh klien A memanggil sumber daya yang tidak ada secara fisik dalam TPM. Situasi ini memicu manajer virtualisasi TBS untuk menjalankan perintah TPM_LoadContext untuk menyediakan sumber daya tersebut, yang mengakhiri sesi transportasi eksklusif klien A.