Skip to content

מפתחות ב־Windows: ספקים ומכלי מפתחות ב־CryptoAPI הוותיק

תאריכים: המקור פורסם ב־25 במאי 2011. התרגום והבדיקה הטכנית נערכו ב־25 באוקטובר 2026.

היקף ועדכון: זהו הסבר על המנגנון הוותיק CryptoAPI ב־Windows. הוא אינו מתאר את כל דרכי אחסון המפתחות במערכת. נוספו הבחנות מול התשתית החדשה יותר, Cryptography Next Generation (CNG), ותוקנו ההסברים על שימושי מפתח, התאמת כרטיס חכם והקשר לתעודה. לא נקראו או יוצאו מפתחות במסגרת הכנת התרגום.

מי מנהל את המפתח?

ב־CryptoAPI, ספק שירותים קריפטוגרפיים — Cryptographic Service Provider, או CSP — מספק פעולות כגון חתימה ופענוח ומנהל את הגישה למפתחות שבאחריותו. לצד ספקים של Microsoft, קיימים ספקים של יצרני חומרה. המקור מ־2011 הזכיר את Athena, ‏Gemalto ו־SafeNet; אלה דוגמאות היסטוריות, לא רשימת מוצרים או ספקים מומלצים כיום.

המונח ״מכל מפתחות״, Key Container, מתאר זיהוי וקיבוץ לוגי של מפתחות אצל הספק. אין להסיק ממנו לבדו שהמפתח נשמר בקובץ רגיל: המימוש יכול להסתמך על תוכנה או על חומרה כגון כרטיס חכם. הגישה תלויה בספק, בהרשאות ובאמצעי ההגנה של המפתח.

כרטיס חכם ומנהל ההתקן שלו

יצרן כרטיס יכול להשתלב דרך מנהל התקן מצומצם, Minidriver, שעובד עם ספק הבסיס של Microsoft. זו ארכיטקטורה נתמכת, ולא בהכרח סימן לכך שהיצרן לא מימש ממשק מלא. בתשתית זו יש תמיכה הן ב־Base CSP והן בספק אחסון מפתחות, KSP, של CNG. ראו את סקירת מנהלי ההתקן של כרטיסים חכמים.

המקור תיאר בחירת מנהל התקן לפי ATR, המידע שהכרטיס מחזיר באתחול. זהו חלק מהתמונה: ההתאמה עשויה להשתמש ב־ATR ובמסכה שלו, ובמסלולי גילוי נוספים לכרטיסים שתואמים למפרטי PIV ו־GIDS. תהליך הגילוי המתועד מפרט את האפשרויות. אין כאן הוראות לשינוי רישום הכרטיס או התקנת מנהל התקן.

שני שימושי מפתח במודל הוותיק

במודל הוותיק של CryptoAPI, שני זוגות המפתחות הסטנדרטיים במכל מובחנים באמצעות KeySpec:

  • AT_KEYEXCHANGE — מפתח לחילופי מפתחות; אצל ספקי RSA ותיקים הוא יכול לשמש לפענוח וגם לחתימה. אין לזהות את השם הזה פשוט עם ״אימות משתמש״.
  • AT_SIGNATURE — מפתח המיועד לחתימה.

לא בכל מכל קיימים בפועל שני הזוגות. ספקים מסוימים מאפשרים גישה גם למפתחות נוספים, וההבחנה הזאת אינה מתארת את מודל המפתחות של CNG. תיעוד Microsoft על KeySpec מסביר את ההבדל בין הספקים הוותיקים ל־CNG.

איך תוכנה מקשרת בין תעודה למפתח?

כאשר שם הספק ושם המכל ידועים, הממשק הוותיק CryptAcquireContext משיג ידית גישה להקשר של הספק והמכל. לאחר מכן CryptGetUserKey יכול לקבל ידית למפתח לפי KeySpec. אלה ידיות לשימוש מורשה, לא בקשה להציג או לייצא את חומר המפתח. תיעוד הממשק מסמן אותו כמיושן ומפנה פיתוח חדש וקיים לממשקי CNG.

תעודה מכילה את המפתח הציבורי, לא את המפתח הפרטי. בהקשר התעודה המקומי עשויים להיות מאפיינים שמקשרים אותה לספק ולמכל שבהם נמצא המפתח הפרטי המתאים. כאשר התעודה זמינה אך ידית המכל אינה זמינה, CryptAcquireCertificatePrivateKey מיועד לקבל גישה למפתח המשויך, אם ההרשאות והספק מאפשרים זאת. החזקה בקובץ התעודה לבדה אינה מעניקה גישה למפתח הפרטי. ראו את תיעוד קבלת הגישה למפתח המשויך לתעודה ואת תיעוד CryptGetUserKey.

לכן, בבדיקת מערכת ותיקה חשוב להבחין בין התעודה, ספק המפתחות, שם המכל וסוג המפתח. אלה פרטים שונים; תקלה בקישור ביניהם אינה סיבה לבטל הגנות או להוציא מפתח מהתקן מוגן.

לקריאת המאמר המקורי באנגלית. קישור המילון הישן במקור הוחלף בתיעוד הרשמי של המושגים והממשקים הנזכרים כאן.

Post a Comment

Previous Post Next Post