Kumpletong gabay sa /dev/tpm0, /dev/tpmrm0, at ang tpm2_pcrread at tpm2_pcr_extend na mga utos sa Linux

Sa mga nagdaang taon, ang mga module ng TPM 2.0 ay napunta mula sa pagiging misteryo ng hardware tungo sa isang karaniwang bahagi ng anumang modernong computer na may UEFI at Secure Boot. Ipinapaliwanag ng artikulong ito kung ano ang /dev/tpm0 at /dev/tpmrm0 at kung paano gamitin ang tpm2_pcrread at tpm2_pcrextend. (pati na rin ang aktwal na utos nito sa tpm2-tools), pati na rin ang pagpapaliwanag kung paano sila umaangkop sa sinusukat na boot, disk encryption, at nilagdaang mga patakaran ng PCR sa Linux.

Ang mga kapaki-pakinabang na dokumentasyon ay umiiral, ngunit ito ay nakakalat sa mga systemd man page, mga entry sa wiki, at napakasiksik na mga post; Dito tinitipon namin ang lahat ng pangunahing impormasyon (mga PCR, praktikal na halimbawa, mga panganib at depensa) upang ang mga teknikal na tao, kahit na hindi sila eksperto sa TPM, ay maaaring gumana sa mga tool na ito nang hindi naliligaw sa mga hindi kilalang detalye.

Ano ang isang TPM 2.0 at kung bakit maaaring may pakialam ka

Ang Trusted Platform Module ay isang security chip na nakatira sa iyong motherboard (o sa loob ng CPU tulad ng fTPM/Intel PTT) at gumaganap bilang isang secure na tindahan, random number generator, at root of trust para sa system. Ito ay pasibo: kung hindi mo ito gagamitin, wala itong magagawa., ngunit kapag isinama mo ito sa iyong daloy ng boot at pag-encrypt ng disk, nagbibigay ito ng pag-verify ng integridad at mga key na protektado ng hardware.

Sa pagsasagawa, binibigyang-daan ka ng TPM 2.0 ng dalawang pangunahing mode ng paggamit sa disk encryption: a) bumuo/mag-save ng malakas na key at protektahan ang paggamit nito gamit ang isang PIN na may anti-brute force lock; b) buhayin ang tinatawag na sinusukat na boot, kung saan Ang bawat bahagi ng boot ay sinusukat sa mga tala ng PCR, kaya ang susi ay "na-unwrapped" lamang kung ang system ay hindi pa pinakialaman (at opsyonal na may pre-boot PIN).

/dev/tpm0 at /dev/tpmrm0: mga pagkakaiba at kung kailan gagamitin ang bawat isa

Sa Linux makakakita ka ng dalawang character na device kapag available ang TPM 2.0. Ang /dev/tpm0 ay ang "raw" na interface ng TPMHabang Ang /dev/tpmrm0 ay naglalantad ng access sa pamamagitan ng Resource Manager (isang manager na nagpaparami ng mga kliyente, namamahala ng mga session at mapagkukunan), na siyang inirerekomenda ng tpm2-tools sa karamihan ng mga sitwasyon.

Kung hindi ka sigurado kung may TPM o wala, maaari mo itong subukan. Kung ang /sys/class/tpm/ ay walang laman o ang utos ng wiki ay walang ibinalik, walang TPM na nakikita: Maaaring hindi ito pisikal na umiiral o maaaring hindi pinagana sa firmware.

# ¿Hay TPM 2.0?
ls /sys/class/tpm/
cat /sys/class/tpm/tpm*/tpm_version_major
# Dispositivos
ls -l /dev/tpm*

Kapag naroroon ang parehong mga node ng device, karaniwang makikita ng tpm2-tools ang /dev/tpmrm0 at awtomatiko itong gagamitin. Kung kailangan mong pilitin ang isang device, tinatanggap ng karamihan sa mga tool –tcti o gumamit ng mga variable ng kapaligiran ng TCTI, ngunit para sa mga karaniwang gawain ay hindi ito karaniwang kinakailangan.

Mga TPM PCR: Paano gumagana ang mga ito at kung ano ang kanilang sinusukat

Ang Mga Register ng Configuration ng Platform ay mga talaan na nag-iimbak ng mga hash (karaniwan ay SHA-256) ng estado ng mga kritikal na bahagi sa bawat yugto ng pag-boot. Sinisimulan ang mga ito sa zero sa ikot ng power-up at maaari lamang "palawigin": hindi kailanman muling isulat o burahin (maliban sa mga kaso ng pag-debug tulad ng PCR 16).

Ang pangunahing operasyon ay ang extension: new_value = SHA256(current_value || SHA256(data))Ito ay kung paano pinagsama-sama ang mga sukat nang hindi pinapayagan ang mga oportunistang pag-reset. Ang pattern na ito ay ginagamit upang sukatin ang firmware, configuration, Secure Boot, kernel, initrd, at mga parameter ng kernel, bukod sa iba pa.

Sa modernong kagamitan, makikita mo ang 24 na PCR (0–23). Ang pinaka-kaugnay na mga sa UEFI boot na may systemd ay:
– PCR 0: firmware code.
– PCR 1: pagsasaayos ng firmware (mga setting ng UEFI).
– PCR 7: Secure Boot status at mga certificate na pinagkakatiwalaan nito.
– PCR 9: (mga) initrd na sinusukat ng kernel.
– PCR 11: UKI (Unified Kernel Image) at mga phase mark sa pamamagitan ng systemd-stub/systemd-pcrphase.
– PCR 12: kernel command line.

Basahin at palawigin ang mga PCR gamit ang tpm2-tools: tpm2_pcrread at tpm2_pcr_extend

Sa tpm2-tools tapos na ang pagbabasa tpm2_pcrread at ang extension na may tpm2_pcrextend. Kung minsan ay makikita mo ang "tpm2_pcr_extend" na tinutukoy bilang ang konseptong operasyon ng pagpapalawak, ngunit Ang aktwal na utos ng suite ay tpm2_pcrextend.

Upang suriin ang kasalukuyang kalagayan ng mga PCR SHA-256, ito ay kasing simple ng:

# Leer PCRs en SHA-256 (ejemplos de índices habituales)
sudo tpm2_pcrread sha256:0,1,7,9,11,12

# O todos los PCRs SHA-256 disponibles
tpm2_pcrread sha256:all

Upang i-extend ang isang PCR na may hash ng arbitrary na data (bilang pedagogical na halimbawa, ang hash ng /etc/passwd), kalkulahin ang SHA-256 at palawigin ito. Tandaan: ang TPM ay hindi tumatanggap ng napakalaking data, ngunit ang hash nito, ayon sa mga limitasyon at disenyo.

# 1) Guardar el hash de /etc/passwd
echo -n $(sha256sum /etc/passwd | cut -d' ' -f1) > passwd.sha

# 2) Extender PCR 7 (ejemplo) con el hash previo
sudo tpm2_pcrextend 7:sha256=$(cat passwd.sha)

# 3) Ver el nuevo valor del PCR 7
tpm2_pcrread sha256:7

Kung gusto mong kopyahin ang extension mathematics sa labas ng TPM, Isasama mo ang kasalukuyang halaga ng PCR (binary) sa bagong hash at ilapat mong muli ang SHA-256 upang suriin ang resulta.

Maaari bang i-reset ang PCR?

Sa normal na kondisyon, hindi. Ang pilosopiya ay ang isang PCR ay lumalaki lamang sa mga extensionMay isang pagbubukod: Ang PCR 16 ay karaniwang nakalaan para sa "pag-debug" at maaaring i-reset sa ilang partikular na daloy, ngunit hindi ito kapaki-pakinabang bilang ugat ng seguridad ng iyong patakaran.

Sinusukat na Boot, LUKS, at systemd-cryptenroll: Pagsasama-sama ng mga Piraso

Kapag isinama mo ang TPM sa iyong disk encryption, maaari mong "itali" ang key unlock sa isang set ng mga PCR. Kung sa kasalukuyang boot ang mga PCR na iyon ay may parehong mga halaga tulad noong inirehistro mo ang susi, ang TPM ay na-unsealed at ang LUKS volume ay awtomatikong nabubuksan (mayroon o walang pre-boot PIN, depende sa iyong configuration).

Ginagawa ito nang napakahusay sa systemd-cryptenroll at systemd-cryptsetup. Ang ideya ay gawin ang iyong volume, i-enroll ang TPM key, at magdagdag ng recovery key. para hindi ka maiwan kung magbabago ang mga sukat (halimbawa, pagkatapos mag-update ng firmware o kernel).

# Ejemplo: crear LUKS, matricular TPM y añadir recuperación (pseudoflujo)
# 1) Crear el volumen con contraseña temporal
sudo cryptsetup luksFormat /dev/nvme0n1p2

# 2) Matricular TPM en LUKS usando PCRs concretos y PIN
sudo systemd-cryptenroll \
  --tpm2-device=auto \
  --tpm2-with-pin=yes \
  --tpm2-pcrs=1+2+3+4 \
  --wipe-slot=empty \
  /dev/nvme0n1p2

# 3) Añadir clave de recuperación aleatoria
sudo systemd-cryptenroll --recovery-key /dev/nvme0n1p2

# 4) Abrir con TPM o con recovery cuando proceda
systemd-cryptsetup attach root /dev/nvme0n1p2 - tpm2-device=auto

Kung pipilitin mong magkaroon ng pagkakaiba (halimbawa, kusa mong i-extend ang PCR 4), hindi na ilalabas ng TPM ang key at kakailanganin mong gamitin ang recovery key. Maaari mong muling i-enroll ang TPM sa ibang pagkakataon gamit ang mga bagong kasalukuyang halaga gamit –wipe-slot=tpm2 at isa pang pagpapatupad ng systemd-cryptenroll.

Aling mga PCR ang pipiliin at bakit

Kung mas may kaugnayang mga PCR ang nili-link mo, mas mababawasan ang surface area, ngunit mas madalas na kailangan mong muling magparehistro pagkatapos ng mga lehitimong pagbabago. Ilang praktikal na pamantayan:
– PCR 7 (Secure Boot): Dapat ay napaka-stable kung hindi magbabago ang iyong keyset.
– PCR 0/1 (firmware at configuration): Ang mga ito ay bihirang magbago; nangangailangan sila ng muling pagpaparehistro pagkatapos mag-update ng firmware o baguhin ang BIOS/UEFI.
– PCR 9/11/12 (kernel, initrd, UKI at cmdline): Ang mga ito ay madalas na nagbabago kung hindi ka gumagamit ng UKI o stable na lagda/patakaran.

Sa ilang mga kapaligiran ay nakitang nag-link lamang ng PCR 7, umaasa sa Secure Boot na nagpapatunay sa kernel at initrd kung sinimulan ang mga ito bilang signed UKI at gumagamit ng systemd-boot na hindi pinapayagan ang pag-edit ng mga parameter ng kernel kapag aktibo ang SB. Gumagana iyon, ngunit kung umaasa ang iyong Secure Boot sa mga third-party na key (tulad ng Microsoft 3rd Party) mas madaling mag-orkestrate ng isang kahaliling boot na nagpapanatili ng PCR 7 at samakatuwid Hindi ito ang pinaka mahigpit na opsyon.

Ang mga patakaran ng UKI at PCR ay nilagdaan: katatagan nang hindi nawawala ang seguridad

Ang isang praktikal na solusyon upang maiwasan ang muling pagrehistro sa tuwing ina-update mo ang kernel ay ang paggamit UKI (Unified Kernel Image) at isang nilagdaang patakaran sa PCRBumubuo ka ng key pair, isailalim ang pampublikong key sa TPM sa pagpaparehistro, at lagdaan ang iyong UKI pagkatapos ng bawat update. Pinagkakatiwalaan ng TPM ang signature na iyon at pinapayagan ang pag-unlock kahit na nagbago ang partikular na kernel hash.

Ginagawa ito ng systemd-measure tool at systemd-ukify helper: ukify packages kernel, initrd at cmdline sa UKI (karaniwang sinusukat sa PCR 11) at nilalagdaan ng systemd-measure ang patakaran. Sa mkinitcpio, maaaring isama ang ukify upang iyon post-install ang pirma ay nagpapatupad mismo.

# Esquema típico (pseudocomandos)
# 1) Crear claves para política PCR firmada
openssl genpkey -algorithm RSA -out /etc/kernel/pcr-initrd.key.pem -pkeyopt rsa_keygen_bits:3072
openssl req -new -x509 -key /etc/kernel/pcr-initrd.key.pem -out /etc/kernel/pcr-initrd.pub.pem -subj "/CN=UKI PCR Policy"

# 2) Configurar ukify/mkinitcpio para generar UKI y firmar política
# (consultar man ukify y systemd-measure para parámetros)

# 3) Matricular en LUKS atando PCRs y clave pública de la política
sudo systemd-cryptenroll \
  --tpm2-device=auto \
  --wipe-slot=tpm2 \
  --tpm2-with-pin=yes \
  --tpm2-pcrs=0+1+2+7 \
  --tpm2-public-key=/etc/kernel/pcr-initrd.pub.pem \
  --tpm2-public-key-pcrs=11 \
  /dev/nvme0n1p2

Sa ganitong paraan, Ang iyong patakaran ay nananatiling matatag laban sa mga pagbabago sa kernel/initrd hangga't patuloy mong pinipirmahan ang UKI gamit ang iyong susi.Kung ire-renew mo ang iyong mga password o babaguhin mo ang iyong PCR set, kakailanganin mong mag-enroll muli.

Mga halimbawa ng mga chain ng pagsukat na may systemd

Sa panahon ng boot, ang systemd-stub at systemd-pcrphase ay nagpapalawak ng mga PCR sa mga partikular na oras. Halimbawa, ang "enter-initrd" ay naitala sa PCR 11, na nagpapahintulot sa isang pag-unlock na maging wasto lamang sa loob ng initrd (pagbabawas ng mga vector kung saan sinusubukan ng isang umaatake na muling gamitin ang susi sa ibang pagkakataon).

Sa mga system na may UKI, ang nilalaman ng UKI ay sinusukat sa PCR 11; sa mga system na walang UKI, sinusukat ng kernel ang initrds sa PCR 9 at masusukat ng bootloader ang cmdline sa PCR 12. Tiyaking sakop mo ang initrd at cmdline sa iyong patakaran, o maaaring may backdoorear ang initrd o boot na may malisyosong cmdline like init=/bin/bash.

Mga totoong panganib: cold boot, TPM sniffing, at higit pa

Ano ang maaaring magkamali? Maraming bagay na dapat malaman kapag nagmomodelo ng mga banta. Pag-atake ng malamig na boot ay mabubuhay pa rin: kung ganap na awtomatiko ang pag-unlock, maaaring ulitin ng isang umaatake ang walang limitasyong mga pagtatangka. Ang malinaw na pagpapagaan ay ang nangangailangan ng pre-boot PIN (PBA), na binabawasan ang mga pagtatangka sa isa sa bawat ikot ng kuryente.

Ang isa pang kategorya ay ang pagsinghot ng mga pag-atake sa TPM busHinihiling ng CPU ang susi, ipinapadala ito ng TPM; kung ang link ay na-tap, ang susi ay maaaring ma-leak. Sa layuning ito, ang systemd ay nagpapatupad ng "parameter encryption" upang ang palitan ay ma-encrypt; Bilang kahalili, ang paggamit ng fTPM/Intel PTT o naka-encrypt na memorya ay nagpapababa ng pagkakalantad. Mayroong medyo abot-kayang mga pampublikong demonstrasyon (kahit na may mga microcontroller) na naglalarawan ng pagiging posible sa mga pangunahing tatak ng laptop.

Mayroon ding mga akademiko at praktikal na kahinaan: TPM-Fail, faultTPM (na may kapansin-pansing epekto sa AMD) at ang kaso bitpixie (CVE-2023-21563)Hindi ito nangangahulugan na ang TPM ay walang silbi, ngunit dapat mong panatilihing napapanahon ang iyong firmware, unawain ang iyong modelo ng pagbabanta, at huwag magtiwala dito nang walang taros.

Katayuan ng BitLocker laban sa mga banta na ito

Sa mundo ng Windows, ang pinakalawak na naka-deploy na disk encryption ay BitLocker. Ngayon ay napansin na ang default na configuration nito (auto unlock lang gamit ang TPM) Hinahayaan nitong bukas ang pinto sa parehong cold boot at TPM channel sniffing, dahil hindi nito ipinapatupad ang systemd-style na parameter encryption. Ginagawa nitong mahina ang ilang corporate computer sa pag-atake sa loob ng ilang minuto.

Ang rekomendasyon doon ay paganahin pre-boot authentication sa pamamagitan ng mga patakaran/registry o CLI, isang bagay na hindi sapat na nakalantad sa karaniwang user. Gayundin, tandaan na tingnan kung saan naka-imbak ang recovery key: madalas itong nasa Microsoft account ng user, na Ito ay isa pang anggulo ng panganib kung hindi kontrolado.

Offensive/Defensive Trick: Palitan ang LUKS root para pilitin ang iyong password

Mayroong isang kawili-wiling vector kapag walang pre-boot authentication. Maaaring i-clone ng isang attacker ang totoong partition ng LUKS, palitan ito ng isa pang LUKS na may parehong UUID at isang password na alam niya, at i-boot ang computer. Dahil ang mga sukat ng PCR ay tumutugma, ang TPM ay naglalabas ng susi, ngunit hindi ito tumutugma sa pekeng LUKS, kaya ang initrd ay magpo-prompt para sa "recovery" key. Sa pamamagitan ng pagpasok ng password na alam ng umaatake, ang iyong system ay tumatakbo bilang root sa initrd, at maaari mong ayusin ang pagnanakaw ng orihinal na key (halimbawa, sa pamamagitan ng pag-mount ng tunay na kopya sa network at paggamit ng systemd-cryptsetup).

Malinaw na mga pagpapagaan: i-activate ang pre-boot authentication, gamitin ang systemd-pcrphase upang maiugnay ang pag-unlock nang mahigpit sa initrd phase, at isaalang-alang din ang pagsukat/pagbubuklod sa target na volume ng LUKS (nangangailangan ng maingat na disenyo upang maiwasan ang mga mabisyo na bilog).

Pagpili ng partitioning at pangalawang key: pinakamahusay na kasanayan

Panatilihin isang recovery key Ito ay sapilitan: kung ang TPM o ang motherboard ay namatay, ang iyong susi na nakatali sa TPM ay walang silbi. Ang LUKS ay nagbibigay-daan sa maramihang mga puwang (ang TPM ay gumagamit ng isa, ang pagbawi ay gumagamit ng isa pa). Bukod pa rito, may mga pakinabang ang paghihiwalay sa / at /home partition: maaari kang mag-apply mahigpit na pagsukat gamit ang TPM a/ at gumamit ng matibay na key o FIDO2/YubiKey device para sa /home, na binabawasan ang kabuuang tiwala sa isang mekanismo.

Ano ang mangyayari kapag nag-update ka ng firmware o kernel?

Kung babaguhin mo ang firmware o pinindot ang mga opsyon sa UEFI, magbabago ang mga PCR tulad ng 0/1 at hindi ilalabas ng TPM ang key hanggang sa muling mag-enroll ka. Para sa kernel at initrd, ang mga pagbabago ay madalasKung hindi ka gagamit ng UKI na may nilagdaang patakaran, maaaring pilitin ka ng bawat update na gamitin ang opsyon sa pagbawi at muling magparehistro sa ibang pagkakataon. With a signed UKI, you just sign it and that's it.

Mga Tala at Obserbasyon ng Komunidad

Sa ilang tanyag na gabay ng ilang partikular na pamamahagi ito ay inirerekomenda itali lamang ang PCR 7 tuwing gumagamit ng UKI at systemd-boot, umaasa sa mga pananggalang ng Secure Boot at ang kawalan ng kakayahang i-edit ang cmdline. Gumagana ito, ngunit may mga panganib kung umaasa ka sa mga third party. Naidokumento na rin ang isang bug sa nakaraan kung saan ang pagpindot sa Enter ay maglalabas ng recovery shell pagkatapos mag-unlock; magandang ideya na panatilihing napapanahon ang iyong mga bersyon upang maiwasan ang mga sorpresa.

Ibinahagi ang mga kawili-wiling komento noong 2025/06: Ang TPM fault ay patuloy na nakakaapekto sa AMD sa ilang lawak; ang mga wiki ay nagdagdag ng mga partikular na seksyon sa nilagdaang mga patakaran ng PCR; at ang installer para sa isang pamamahagi na nag-aalok ng FDE na may TPM bilang isang pang-eksperimentong tampok ay nasubok, na may ilang praktikal na hiccups (nangangailangan ng pagbawi sa unang boot, dependency sa mga snap, double disk encryption), isang isyu na nararapat sa isang mas malalim na pag-audit.

Ang isang follow-up na nakatuon sa disk encryption sa Windows ay na-publish noong 2025/07. Ang pangkalahatang konklusyon ay nagpapatibay sa pangangailangan para sa PBA at pag-encrypt ng TPM channel., pati na rin ang paglilimita sa pag-asa sa mga third-party na key sa Secure Boot.

Mga tip sa pagpapatakbo gamit ang tpm2-tools at systemd

Para sa pang-araw-araw na paggamit: Mag-install ng tpm2-tools at tpm2-tss. Gumagamit ng /dev/tpmrm0 bilang default, at tpm2_pcrread/tpm2_pcrextend para sa pagsubok at pag-eksperimento sa mga PCR. Iwasan ang pagpapalawig ng mga PCR ng produksyon na may arbitrary na data: gawin ito sa mga lab o gumamit ng PCR 16 para sa pagsubok.

Kapag nag-enroll sa systemd-cryptenroll: –tpm2-device=auto nakakakita ng TPM; –tpm2-may-pin nagdadagdag ng PBA; –tpm2-pcrs=… piliin ang iyong mga PCR; –tpm2-public-key=… at –tpm2-public-key-pcrs=… i-activate ang isang nilagdaang patakaran sa PCR (hal., nakatali sa PCR 11 para sa UKI). Huwag kalimutan –punasan-slot kapag gusto mong linisin ang isang nakaraang slot.

Kung wala kang TPM at pinapahintay ka ng systemd sa boot

Paminsan-minsan, pagkatapos ng pag-update, sinusubukan ng isang serbisyo na gamitin ang TPM kahit na hindi ito nakikita ng iyong machine, na nagiging sanhi ng mga timeout sa boot. Suriin muna kung walang /dev/tm* ang lumalabas o mga entry sa /sys/class/tpm.

# Verificación rápida
ls /dev/tpm*
ls /sys/class/tpm/

Kung walang TPM, suriin ang iyong /etc/crypttab walang mga pagpipilian tulad ng tpm2-device=autoKung mayroon sila, tanggalin ang mga ito at muling buuin ang iyong initrd. Maaari mo ring i-disable ang yugto ng pagsukat sa mga computer na walang TPM:

# 1) Eliminar referencias TPM en /etc/crypttab y regenerar initrd
sudo mkinitcpio -P    # (o dracut/rebuildinitrd según distro)

# 2) Evitar carga de módulos TPM si el firmware publica algo extraño
echo -e "blacklist tpm\nblacklist tpm_tis\nblacklist tpm_crb" | sudo tee /etc/modprobe.d/no-tpm.conf

# 3) Opcional: evitar pcrphase si te da problemas
sudo systemctl mask systemd-pcrphase.service

Inaalis nito ang hindi kinakailangang paghihintay kung ang iyong kagamitan ay walang TPM. Kung paganahin mo sa ibang pagkakataon ang TPM sa BIOS/UEFI, alisin ang blacklist at i-unmask ang unit para mabawi ang mga sukat.

Mabuting gawi at desisyon ng tiwala

Ang ilang mga tao ay maingat sa TPM dahil ito ay isang "itim na kahon," tulad ng mga self-encrypting disk. Ito ay isang makatwirang pagdududa. Suriin ang iyong modelo ng pagbabanta at binabalanse ang kakayahang magamit, privacy, at pagpapanatili. Para sa maraming tao, ang TPM+PBA+signed UKI ay isang malaking security leap na walang labis na alitan.

Sa hardware na nagpapahintulot nito, magdagdag naka-encrypt na memorya at iwasang umasa sa mga third-party na key sa Secure Boot; limitahan ang chain sa iyong sariling mga susi hangga't maaari. Panatilihing na-update ang firmware at kernel upang maisama ang mga pagpapagaan para sa mga na-publish na kahinaan.

Ang pag-master ng /dev/tpm0, /dev/tpmrm0, at ang tpm2_pcrread/tpm2_pcr_extend na mga operasyon ay nagbubukas ng pinto sa nasusukat na boot at matatag na disk encryption sa Linux; gamit ang UKI at isang nilagdaang patakaran sa PCR, makakamit mo ang katatagan ng pagpapatakbo, at ang pagdaragdag ng pre-boot PIN ay pinoprotektahan ka rin mula sa mas praktikal na mga pag-atake. Ang susi ay ang pumili ng mabuti sa mga PCR, lagdaan kung ano ang madalas na nagbabago at palaging panatilihin ang isang mahusay na susi sa pagbawi..