אחסון מפתחות קריפטוגרפיים

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

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

הגדרת גבול המשמורת

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

בחרו אמצעי אחסון מתאים

לצורך פיתוח מקומי, בדיקות מבוקרות או העברה מאובטחת למשמורת, אפשר לייצא מפתח לקובץ בעל הרשאות מוגבלות. בפלטפורמת Unix נתמכת, יש ליצור ספריית מפתחות חדשה באמצעות kagami:

cargo run --bin kagami -- keys --algorithm ed25519 --out-dir ./client-key

ספריית האב חייבת להיות קיימת. ספריית היעד חייבת להיות חדשה או כבר בבעלות המשתמש הנוכחי, במצב 0700, ללא קישורים סמליים וריקה. Kagami כותב את public.key ואת private.key במצב 0600; האפשרות --pop כותבת גם את pop.hex. הפקודה נכשלת בפלטפורמות שבהן Kagami אינו יכול לאכוף את כללי מערכת הקבצים המגבילים גישה לבעלים בלבד.

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

לייצור, יש להעדיף גבול משמורת מבוקר, כגון:

• מודול אבטחה חומרי או מחסן מפתחות בעלת תמיכה חומרית
• מערכת הפעלה או מחסן מפתח נייד
• שירות חתימה מבודד
• מנהל סודות שמוסר מפתח רק לעומס עבודה מורשה

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

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

הגנה על זרימת העבודה של חתימות

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

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

גיבוי ושחזור מפתחות

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

אל תניח כי פורמט mnemonic של ארנק לא קשור יכול לייצג מפתח פרטי Iroha. השתמש רק בפורמט התאוששות שתומך ונבדק על ידי מערכת האחסון הנבחרת.

החלפת מפתחות שנחשפו או הוצאו משימוש

יש להתכונן להחלפה לפני תקרית. הנוהל חייב לציין:

1. מי יכול להכריז שמפתח נחשף או הוצא משימוש
2. כיצד מבודד החותם הנפגע
3. כיצד נוצר מפתח חדש ומוכנס למשמורת מאושרת
4. עבור חשבון, כיצד החלפה מורשית של הבקר או שחזור חברתי יוצרים AccountId קנוני חלופי ומעבירים את המצב המקושר
5. עבור צומת או עמית, כיצד סיבוב או השבתה מורשים בשרשרת של מפתח ההסכמה מתואמים עם BLS PoP, מדיניות ההפעלה והחפיפה, תצורת המפתח המקומית, trusted_peers_pop וטופולוגיית הפריסה
6. כיצד תצורות, יישומים ומפעילים תלויים מאמצים את ה-AccountId החדש, את המפתח הציבורי או את זהות העמית
7. כיצד ניתן להסיר את סמכות המפתח הישן, ולהארכיב או להרוס את העותקים שלו
8. כיצד ניתן לאמת את הרשת והיישומים תלויים בהן לאחר מכן

WARNING

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

ראו הדורת מפתחות קריפטוגרפיות , ביטחון פעיל, ו עקרונות אבטחה .