עורך: יובל סיני

רקע

מאמר זה מהווה מבוא ל RFC 3161 Time-Stamp Protocol (TSP). שיכונה להלן פרוטוקול TSP.

חוק חתימה אלקטרונית, התשס"א-2001 מהווה את התשתית החוקית במדינת ישראל ליישום חתימה אלקטרונית.שנה לאחר יציאת החוק, מדינת ישראל הוציאה תקנה הנכללת תחת צו חתימה אלקטרונית (קביעת תוספות לחוק), התשס"ב –2002 המוסיפה סיגיים לתקפות החתימה האלקטרונית בעת ביצוע פעולות משפטיות שונות. לפיכך, אחת השאלות החשובות שיש לשאול כיום הינה, כיצד נוכל להבטיח כי בעל החתימה האלקטרונית, אכן ביצע את הפעולה המשפטית בזמן נתון.

אחת הטעויות הנפוצות בתחום אבטחת המידע כיום הינה הסברה כי קיום תשתית Public key infrastructure (PKI) מבטיח לנו כי בעל החתימה האלקטרונית, אכן ביצע את הפעולה המשפטית בזמן נתון. מעבר לסוגיה של אבטחת המידע הקשורה לניהול המתודולוגי של סביבת ה PKI,  עולה השאלה האם סביבת ה PKI במתכונתה קיום, עונה לכלל הדרישות על מנת לשמש ראיה משפטית אמינה בבית המשפט.

ובכן, לדעתי האישית, אחד הגורמים המשפיעים על תקפות החתימה האלקטרונית הינו "זמן". למעשה, מרבית המערכות בתחום המחשוב מאפשרות לנו לשנות את הגדרות ה"זמן" במערכת. לפיכך, אם נניח כי אנו בעלי תעודה אלקטרונית שתוקפה פג, נוכל לשנות את שעון המערכת, ובכך להפוך את התעודה שהיתה פגת תוקף, לפעילה. אומנם שימוש ב Certificate Revocation List (CRL) או ב certificate status protocol (OCSP) מאפשרים לאמת כי את התעודה האלקטרונית אינה פגה תוקף, אך הדבר בהגדרות המערכת המנסה לזהות את הפונה אליה. בהנחה שתשתית ה PKI  הוגדרה כהלכה, נסיון לשימוש בתעודה אלקטרונית שפג תוקפה יכשל.

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

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

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

RFC 3161 Time-Stamp Protocol (TSP).

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

ה TSP  יכול לסייע לנו במספר תחומים, וביניהם:

א.       אימות כי פעולה של חתימה אלקטרונית של פלוני, התבצעה בזמן נתון (שאינו תלוי ברמת השרת המקומי).

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

ג.        שילוב של זמן ממקור מהימן עם חתימה על תוכן אפליקטיבי.

ד.       תמיכה בתקני אבטחה רבים, כדוגמת CAdES-T ו-XAdES-T של ETSI.

יישום פרוטוקול ה TSP נפוץ בעת עבודה עם רכיבי Hardware security module (HSM), ולפיכך מהווה גורם חשוב בהעלאת רמת האמינות והמהימנות של תשתית ה PKI.

בעיון בתקנות חתימה אלקטרונית (חתימה אלקטרונית מאובטחת, מערכות חומרה ותוכנה ובדיקת בקשות), התשס"ב 2001- 1, אפשרי לראות כי הסוגיה הנ"ל לא זכתה להתיחסות. ראוי אף לציין כי התקנות לא עודכנו זמן רב, ולפיכך מן הראוי שהגורמים הרלוונטים יעדכנו את התקנות בהתאם לרוח התקופה.

מדוע לא לעבוד עם פרוטוקול NTP?

אני מניח שרבים בתחום במחשוב ישאלו את השאלה: מדוע ישנו צורך לעבוד עם פרוטוקול TSP, כאשר נוכל ליישם ניהול זמן ע"י פרוטוקול Network Time Protocol (NTP). בעקבות שיפורים שונים בפרוטקול ה NTP בגרסתו העדכנית (4), אכן הוספו יכולות חדשות ומשופרות לפרוטוקול. אף עם זאת, קיימות עדיין מספר רב של מגבלות, כדוגמת:

א.       אי השתלבות מלאה של פרוטוקול ה NTP בתשתית ה PKI.

ב.       פרוטוקול ה NTP לא תוכנן לביצוע המטלות השונות (כגון: ביצוע חתימה אלקטרנוית מאומתת), הנתמכות באופן מובנה בפרוטוקול ה TSP.

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

ג.        פרוטוקול ה NTP בגרסה 4 מהווה הרחבה לא רשמית, לפיכך ראוי לשקול בכובד ראש את השימוש בפרוטוקול זה בסביבות רגישות.

ד.       פרוטוקול ה NTP בגרסה 4 מכיל תמיכה לאחור (לא כולל גרסה 1, שאינה נתמכת כיום), ולפיכך הינו פגיע למגבלות הקיימות בגרסאות הקודמות של הפרוטוקול.

סיכום ומסקנות

מאמר זה כלל מבוא לפרוטוקול RFC 3161 Time-Stamp Protocol (TSP). כמו כן, המאמר כולל המלצה ליישום פרוטוקול TSP בעת עבודה עם סביבת PKI . ראוי לציין כי ראוי להשתמש במקור סינכרון זמן רשמי )חיצוני(, התומך בפרוטוקול TSP לשם מתן מהימנות גבוהה למערך ה PKI. 

למידע נוסף, אנא עיין ב:

Enhancing e-Government Services through Digital Time Stamping: Time Stamping System Specifications, Communications of the IBIMA Volume 5, 2008