בשנים האחרונות, מודולי TPM 2.0 הפכו מתעלומת חומרה לחלק נפוץ בכל מחשב מודרני עם UEFI ואתחול מאובטח. מאמר זה מסביר מהם /dev/tpm0 ו- /dev/tpmrm0 וכיצד להשתמש ב- tpm2_pcrread ו- tpm2_pcrextend. (כמו גם הפקודה בפועל ב-tpm2-tools), וכן הסבר כיצד הם משתלבים במדיניות אתחול מדוד, הצפנת דיסק ומדיניות PCR חתומה בלינוקס.
קיים תיעוד שימושי, אך הוא מפוזר בין דפי man של systemd, ערכי ויקי ופוסטים צפופים מאוד; כאן אנו אוספים את כל המידע המרכזי (PCRs, דוגמאות מעשיות, סיכונים והגנות) כך שאנשים טכניים, גם אם אינם מומחי TPM, יוכלו לעבוד עם הכלים הללו מבלי ללכת לאיבוד בפרטים מעורפלים.
מהו TPM 2.0 ולמה זה אולי אכפת לך
מודול פלטפורמה מהימנה (Trusted Platform Module) הוא שבב אבטחה שנמצא על לוח האם שלך (או בתוך המעבד כמו fTPM/Intel PTT) ופועל כמאגר מאובטח, מחולל מספרים אקראיים ושורש אמון עבור המערכת. זה פסיבי: אם לא משתמשים בו, הוא לא עושה כלום., אבל כשאתה משלב אותו בתהליך האתחול ובהצפנת הדיסק שלך, הוא מספק אימות שלמות ומפתחות מוגנים על ידי חומרה.
בפועל, TPM 2.0 מאפשר לך שני מצבי שימוש עיקריים בהצפנת דיסק: א) יצירה/שמירה של מפתח חזק והגנה על השימוש בו באמצעות קוד סודי עם נעילת Anti-Brute Force; ב) הפעלת מה שנקרא אתחול מדוד, כאשר כל רכיב אתחול נמדד ברשומות PCR, כך שהמפתח "נפתח" רק אם המערכת לא טופלה (ואופציונלי באמצעות קוד PIN לפני אתחול).
/dev/tpm0 ו- /dev/tpmrm0: הבדלים ומתי להשתמש בכל אחד מהם
בלינוקס תראו שני התקני תווים כאשר TPM 2.0 זמין. /dev/tpm0 הוא הממשק ה"גולמי" של ה-TPMבעוד /dev/tpmrm0 חושף גישה דרך מנהל המשאבים (מנהל שמכפיל לקוחות, מנהל הפעלות ומשאבים), והוא זה שמומלץ על ידי tpm2-tools ברוב התרחישים.
אם אינך בטוח אם קיים TPM או לא, תוכל לבצע בדיקה חמה שלו. אם /sys/class/tpm/ ריק או שפקודת הוויקי לא מחזירה דבר, לא נראה TPM: ייתכן שהוא לא קיים פיזית או שהוא מושבת בקושחה.
# ¿Hay TPM 2.0?
ls /sys/class/tpm/
cat /sys/class/tpm/tpm*/tpm_version_major
# Dispositivos
ls -l /dev/tpm*
כאשר שני צמתי המכשיר נוכחים, tpm2-tools בדרך כלל יזהה את /dev/tpmrm0 וישתמש בו באופן אוטומטי. אם אתה צריך לכפות מכשיר, רוב הכלים מקבלים –tcti או להשתמש במשתני סביבה של TCTI, אך עבור משימות נפוצות זה בדרך כלל לא הכרחי.
בדיקות TPM PCR: כיצד הן פועלות ומה הן מודדות
אוגרי תצורת פלטפורמה (Platform Configuration Registry) הם רשומות המאחסנות קוד גיבוב (hash) (בדרך כלל SHA-256) של מצב הרכיבים הקריטיים בכל שלב אתחול. הם מאותחלים לאפס במחזור ההפעלה וניתן "להאריך" אותם רקלעולם אל תכתוב מחדש או תמחק (למעט במקרי ניפוי שגיאות כמו PCR 16).
הפעולה הבסיסית היא ההרחבה: ערך_חדש = SHA256(ערך_נוכחי || SHA256(נתונים))כך משורשרות מדידות יחד מבלי לאפשר איפוסים אופורטוניסטיים. תבנית זו משמשת למדידת קושחה, תצורה, אתחול מאובטח, ליבה, initrd ופרמטרים של ליבה, בין היתר.
בציוד מודרני תראו 24 PCRs (0-23). הרלוונטיים ביותר באתחול UEFI עם systemd הם:
– PCR 0: קוד קושחה.
– PCR 1: תצורת קושחה (הגדרות UEFI).
– PCR 7: סטטוס אתחול מאובטח ואישורים שהוא בוטח בהם.
– PCR 9: initrd(s) נמדדו על ידי הליבה.
– PCR 11: UKI (תמונה מאוחדת של ליבה) וסימני פאזה דרך systemd-stub/systemd-pcrphase.
– PCR 12: שורת פקודה של הליבה.
קריאה והרחבה של PCRs בעזרת כלי tpm2: tpm2_pcrread ו-tpm2_pcr_extend
בכלי tpm2 הקריאה מתבצעת באמצעות tpm2_pcrread וההרחבה עם tpm2_pcrextendלעיתים תראו את "tpm2_pcr_extend" כפעולה מושגית של הרחבה, אך פקודת ה-suite בפועל היא tpm2_pcrextend.
כדי לבדוק את המצב הנוכחי של בדיקות ה-PCR SHA-256, זה פשוט כמו:
# 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
כדי להרחיב PCR עם הגיבוב של נתונים שרירותיים (כדוגמה פדגוגית, הגיבוב של /etc/passwd), חשב את ה-SHA-256 והרחב אותו. זכרו: ה-TPM לא מקבל נתונים ענקיים, אבל ה-hash שלו, לפי מגבלות ותכנון.
# 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
אם ברצונך לשחזר את מתמטיקה של ההרחבה מחוץ ל-TPM, אתה משרשר את ערך ה-PCR הנוכחי (בינארי) עם ה-hash החדש. ואתה מחיל שוב את SHA-256 כדי לבדוק את התוצאה.
האם ניתן לאפס PCR?
בתנאים רגילים, לא. הפילוסופיה היא ש-PCR גדל רק עם הרחבות.יש יוצא מן הכלל אחד: PCR 16 שמור בדרך כלל ל"ניפוי שגיאות" וניתן לאפס אותו בזרימות מסוימות, אך הוא אינו שימושי כבסיס האבטחה של המדיניות שלך.
אתחול מדוד, LUKS ו-systemd-cryptenroll: חיבור החלקים
כאשר אתה משלב את ה-TPM בהצפנת הדיסק שלך, אתה יכול "לקשור" את פתיחת המפתח לקבוצת PCRs. אם באתחול הנוכחי, ל-PCRs יש את אותם ערכים כמו בעת רישום המפתח, האטימה של ה-TPM נפרשת ואמצעי האחסון LUKS נפתח אוטומטית (עם או בלי קוד PIN לפני אתחול, בהתאם לתצורה שלך).
זה נעשה בצורה יפה מאוד עם systemd-cryptenroll ו- systemd-cryptsetup. הרעיון הוא ליצור את אמצעי האחסון שלך, לרשום את מפתח ה-TPM ולהוסיף מפתח שחזור. כך שלא תישאר בחוץ אם המדידות משתנות (לדוגמה, לאחר עדכון קושחה או ליבה).
# 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
אם כופים פער (לדוגמה, אתה מאריך את PCR 4 בכוונה), ה-TPM לא ישחרר עוד את המפתח ותצטרך להשתמש במפתח השחזור. בהמשך תוכל לרשום מחדש את ה-TPM עם הערכים הנוכחיים החדשים באמצעות –חריץ-מחק=tpm2 וביצוע נוסף של systemd-cryptenroll.
אילו PCRs לבחור ומדוע
ככל שתקשרו יותר PCRs רלוונטיים, כך תקטינו את שטח הפנים, אך כך תצטרכו להירשם מחדש לעתים קרובות יותר לאחר שינויים לגיטימיים. כמה קריטריונים מעשיים:
– PCR 7 (אתחול מאובטח): אמור להיות יציב מאוד אם מערך המפתחות שלך לא משתנה.
– PCR 0/1 (קושחה ותצורה): אלה משתנים לעתים רחוקות; הם דורשים רישום מחדש לאחר עדכון קושחה או שינוי ה-BIOS/UEFI.
– PCR 9/11/12 (ליבה, initrd, UKI ו-cmdline): אלה משתנים לעתים קרובות אם אינך משתמש ב-UKI או בחתימה/מדיניות יציבה.
בסביבות מסוימות נראה כי הוא מקשר רק את PCR 7, תוך הסתמכות על Secure Boot המאמת את הליבה ואת initrd אם הם מופעלים כ- UKI חתום ומשתמש ב- systemd-boot אשר לא מאפשר עריכת פרמטרים של הליבה כאשר SB פעילזה עובד, אבל אם האתחול המאובטח שלך מסתמך על מפתחות של צד שלישי (כגון Microsoft 3rd Party), קל יותר לתאם אתחול חלופי שישמור על PCR 7 ולכן... זו לא האפשרות הכי מגבילה.
מדיניות UKI ו-PCR שנחתמה: יציבות מבלי לאבד ביטחון
פתרון מעשי כדי להימנע מרישום מחדש בכל פעם שמעדכנים את הליבה הוא להשתמש ב- UKI (תמונת ליבה מאוחדת) ומדיניות PCR חתומהאתה יוצר זוג מפתחות, קושר את המפתח הציבורי ל-TPM בעת ההרשמה, וחותם על ה-UKI שלך לאחר כל עדכון. ה-TPM סומך על חתימה זו ומאפשר ביטול נעילה גם אם גיבוב הליבה הספציפי משתנה.
כלי systemd-measure ועוזר systemd-ukify הופכים את זה לקל: ukify אורז את הליבה, initrd ו-cmdline לתוך UKI (בדרך כלל נמדד ב-PCR 11) ו-systemd-measure חותם על המדיניות. עם mkinitcpio, ניתן לשלב ukify כך ש לאחר ההתקנה החתימה מבצעת את עצמה.
# 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
בדרך זו, המדיניות שלך נשארת יציבה כנגד שינויים בליבת הקרנל/initrd כל עוד אתה ממשיך לחתום על ה-UKI עם המפתח שלך.אם תחדשו את הסיסמאות שלכם או תשנו את ערכת ה-PCR שלכם, תצטרכו להירשם מחדש.
דוגמאות לשרשראות מדידה עם systemd
במהלך האתחול, systemd-stub ו- systemd-pcrphase מאריכים PCRs בזמנים ספציפיים. לדוגמה, "enter-initrd" נרשם ב-PCR 11, מה שמאפשר לפתיחה להיות תקפה רק בתוך ה-initrd (מה שמפחית וקטורים שבהם תוקף מנסה לעשות שימוש חוזר במפתח מאוחר יותר).
במערכות עם UKI, תכולת ה-UKI נמדדת ב-PCR 11; במערכות ללא UKI, הגרעין מודד initrds ב-PCR 9 ומנהל האתחול יכול למדוד את ה-cmdline ב-PCR 12. ודא שאתה מכסה את initrd ו-cmdline במדיניות שלך, אחרת מישהו יכול. אחורית ה-initrd או האתחול עם שורת cmd זדונית כמו init=/bin/bash.
סיכונים אמיתיים: אתחול קר, ריח TPM ועוד
מה יכול להשתבש? כמה דברים שכדאי לדעת כשמדמים איומים. התקפות אתחול קר עדיין בת קיימא: אם הפתיחה אוטומטית לחלוטין, תוקף יכול לחזור על ניסיונות ללא הגבלה. הדרך הברורה להפחתת הסיכון היא לדרוש קוד סודי לפני אתחול (PBA), מה שמפחית את הניסיונות לאחד בכל מחזור הפעלה.
קטגוריה נוספת היא ה- התקפות הרחה על אוטובוס TPMהמעבד מבקש את המפתח, ה-TPM שולח אותו; אם מקישים על הקישור, המפתח עלול לדלוף. לשם כך, systemd מיישם "הצפנת פרמטרים" כך שהחילוף מוצפן; לחלופין, שימוש ב-fTPM/Intel PTT או זיכרון מוצפן מפחית את החשיפה. ישנן הדגמות פומביות במחירים נוחים יחסית (אפילו עם מיקרו-בקרים) הממחישות את ההיתכנות במחשבים ניידים של מותגים גדולים.
היו גם נקודות תורפה אקדמיות ומעשיות: TPM-Fail, faultTPM (עם השפעה ניכרת על AMD) והמקרה ביטפיקסי (CVE-2023-21563)זה לא אומר שה-TPM חסר תועלת, אבל כדאי לשמור על הקושחה מעודכנת, להבין את מודל האיום שלכם ולא לסמוך עליו באופן עיוור.
סטטוס BitLocker כנגד איומים אלה
בעולם Windows, הצפנת הדיסק הנפוצה ביותר היא BitLocker. כעת צוין כי תצורת ברירת המחדל שלה (פתיחה אוטומטית רק עם TPM) זה משאיר את הדלת פתוחה הן לאתחול קר והן לזיהוי ערוצי TPM, מכיוון שהוא אינו מיישם הצפנת פרמטרים בסגנון systemd. זה הופך מחשבים ארגוניים מסוימים לפגיעים להתקפה תוך דקות.
ההמלצה שם היא לאפשר אימות טרום-אתחול דרך מדיניות/רישום או ממשק שורת פקודה (CLI), דבר שאינו חשוף מספיק למשתמש הממוצע. כמו כן, זכרו לבדוק היכן מאוחסן מפתח השחזור: לעתים קרובות הוא נמצא בחשבון Microsoft של המשתמש, אשר זוהי זווית סיכון נוספת אם לא נשלט.
טריק התקפי/הגנתי: החלף את ה-root של LUKS כדי לאלץ את הסיסמה שלך
יש וקטור מעניין כאשר אין אימות טרום-אתחול. תוקף יכול לשכפל את מחיצת LUKS האמיתית, החלף אותו ב-LUKS אחר עם אותו UUID וסיסמה שהוא יודע, ולאתחל את המחשב. מכיוון שמדידות ה-PCR תואמות, ה-TPM משחרר את המפתח, אך הוא אינו תואם ל-LUKS המזויף, כך שה-initrd יבקש את מפתח ה-"recovery". על ידי הזנת הסיסמה הידועה לתוקף, המערכת שלך פועלת כ-root ב-initrd, ולאחר מכן תוכל לתזמן את גניבת המפתח המקורי (לדוגמה, על ידי טעינת העותק האמיתי ברשת ושימוש ב-systemd-cryptsetup).
אמצעי הקלה ברורים: הפעל אימות טרום-אתחול, למנף את systemd-pcrphase כדי לקשור את הנעילה אך ורק לשלב initrd, ולשקול מדידה/קשירה גם של נפח LUKS היעד (דורש תכנון קפדני כדי למנוע מעגלי קסמים).
בחירת חלוקה ומפתח שני: שיטה מומלצת
שמור מפתח התאוששות זה חובה: אם ה-TPM או לוח האם מתים, המפתח שלך הקשור ל-TPM לא שימושי. LUKS מאפשר מספר חריצים (TPM משתמש באחד, recovery משתמש באחר). בנוסף, להפרדת המחיצות / ו-/home יש יתרונות: אתה יכול להחיל מדידה קפדנית עם TPM a/ ולהשתמש במפתח חזק או בהתקן FIDO2/YubiKey עבור /home, מה שמפחית את האמון הכללי במנגנון יחיד.
מה קורה כשאתה מעדכן קושחה או ליבה?
אם תשנה קושחה או תיגע באפשרויות UEFI, PCRs כמו 0/1 ישתנו וה-TPM לא ישחרר את המפתח עד שתירשם מחדש. עבור ליבה ו-initrd, שינויים הם תכופיםאם אינך משתמש ב-UKI עם מדיניות חתומה, כל עדכון עלול לאלץ אותך להשתמש באפשרות השחזור ולרשום מחדש מאוחר יותר. עם UKI חתום, אתה פשוט חותם עליו וזהו.
הערות ותצפיות קהילתיות
בכמה מדריכים פופולריים של הפצות מסוימות הומלץ קשירת PCR 7 בלבד בכל פעם שמשתמשים ב-UKI וב-systemd-boot, תוך הסתמכות על אמצעי ההגנה של Secure Boot וחוסר היכולת לערוך את שורת ה-cmd. זה עובד, אבל יש סיכונים אם מסתמכים על צדדים שלישיים. בעבר תועד גם באג שבו לחיצה על Enter הייתה מעלה מעטפת שחזור לאחר ביטול הנעילה; מומלץ לשמור על הגרסאות מעודכנות כדי להימנע מהפתעות.
תגובות מעניינות פורסמו ב-2025/06: תקלת TPM ממשיכה להשפיע על AMD במידה מסוימת; אתרי ויקי הוסיפו סעיפים ספציפיים על מדיניות PCR חתומה; והמתקין עבור הפצה המציעה FDE עם TPM כתכונה ניסיונית נבדק, עם כמה תקלות מעשיות (דרישת שחזור באתחול הראשון, תלות ב-snaps, הצפנת דיסק כפול), בעיה ש... ראוי לביקורת מעמיקה יותר.
מאמר המשך שהתמקד בהצפנת דיסק ב-Windows פורסם בשנת 2025/07. המסקנה הכוללת מחזקת את הצורך ב-PBA ובהצפנת ערוץ ה-TPM., וכן הגבלת התלות במפתחות של צד שלישי ב-Secure Boot.
טיפים תפעוליים עם tpm2-tools ו-systemd
לשימוש יומיומי: התקן את tpm2-tools ואת tpm2-tss. משתמש ב-/dev/tpmrm0 כברירת מחדל, ו- tpm2_pcrread/tpm2_pcreextend לבדיקה וניסויים עם PCRs. הימנעו מהארכת PCRs לייצור עם נתונים שרירותיים: עשו זאת במעבדות או השתמשו ב- PCR 16 לבדיקה.
בעת הרשמה ל-systemd-cryptenroll: –tpm2-device=אוטומטי מזהה TPM; –tpm2-עם-פין מוסיף PBA; –tpm2-pcrs=… בחר את ה-PCR שלך; –tpm2-public-key=… ו- –tpm2-public-key-pcrs=… הפעל מדיניות PCR חתומה (למשל, קשורה ל-PCR 11 עבור UKI). אל תשכח –חריץ-לנגב כאשר ברצונך לנקות חריץ קודם.
אם אין לך TPM ו-systemd גורם לך להמתין לאתחול
לעיתים, לאחר עדכון, שירות מנסה להשתמש ב-TPM למרות שהוא אינו גלוי במחשב שלך, מה שגורם להפסקות זמן בעת האתחול. ראשית, בדוק שלא מופיע /dev/tpm* וגם לא ערכים ב-/sys/class/tpm.
# Verificación rápida
ls /dev/tpm*
ls /sys/class/tpm/
אם אין TPM, בדוק את /etc/crypttab אין אפשרויות כמו tpm2-device=autoאם הם קיימים, מחק אותם ובנה מחדש את ה-initrd שלך. ניתן גם להשבית את שלב המדידה במחשבים ללא 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
זה מבטל המתנה מיותרת אם לציוד שלך חסר TPM. אם תפעילו מאוחר יותר את ה-TPM ב-BIOS/UEFI, הסר את הרשימה השחורה וחסל את המסכה של היחידה כדי לשחזר את המדידות.
שיטות עבודה מומלצות והחלטות אמון
יש אנשים שנזהרים מ-TPM מכיוון שהוא "קופסה שחורה", בדיוק כמו דיסקים שמצפינים את עצמם. זהו ספק סביר. הערכת מודל האיום שלך ומאזן בין שימושיות, פרטיות ותחזוקה. עבור אנשים רבים, TPM+PBA+signed UKI הוא קפיצת מדרגה אבטחתית ענקית ללא חיכוכים מוגזמים.
בחומרה שמאפשרת זאת, הוסף זיכרון מוצפן ולהימנע מהסתמכות על מפתחות של צד שלישי ב-Secure Boot; להגביל את השרשרת למפתחות שלך במידת האפשר. לשמור על קושחה וליבת נתונים מעודכנים כדי לשלב פתרונות להפחתת נקודות תורפה שפורסמו.
שליטה בפעולות /dev/tpm0, /dev/tpmrm0, ובפעולות tpm2_pcrread/tpm2_pcr_extend פותחת את הדלת לאתחול מדוד ולהצפנת דיסק חזקה בלינוקס; עם UKI ומדיניות PCR חתומה, משיגים יציבות תפעולית, והוספת קוד PIN לפני אתחול גם מגינה מפני התקפות מעשיות יותר. המפתח הוא לבחור היטב את ה-PCR, לחתום על מה שמשתנה לעתים קרובות ולשמור תמיד מפתח שחזור טוב..
