Data Pulse / Product Note

חתימה דיגיטלית על מסמך — 10 שניות, מהנייד

פעם, כדי לקבל מסמך חתום, היה צריך להדפיס, לחתום, לסרוק ולשלוח בחזרה — וכל שלב כזה מאבד זמן ועסקאות. אצלנו ב‑Data Pulse זה קישור אחד: הלקוח פותח בנייד, חותם באצבע, והחתימה מוטבעת אוטומטית ב‑PDF. הנה איך זה עובד.

✓ מאובטח · ללא התחברות
מסמך לחתימה · ARQ‑1042
לכבוד: ישראל ישראלי
חתימת הלקוח

The Flow

ארבעה צעדים, בלי חיכוך

יוצרים קישור חתימה

בלחיצה על "שלח לחתימה" נוצר קישור ייחודי למסמך, והמסמך עובר לסטטוס "נשלח".

הלקוח פותח — בלי התחברות

הקישור פותח דף נקי עם המסמך המלא (RTL, מותאם לנייד). אין צורך בחשבון או בסיסמה.

חותם על המסך

הלקוח חותם באצבע/עכבר על משטח חתימה (canvas), ממלא שם וטלפון — ולוחץ "אשר וחתום".

החתימה מוטבעת אוטומטית

המסמך מסומן "נחתם" עם חותמת זמן וזהות החותם, והחתימה מוטבעת ישירות ב‑PDF הרשמי.

Under The Hood

מאובטח — גם בלי מסך התחברות

"בלי התחברות" לא אומר "בלי אבטחה". הקישור הפתוח מוגן בכמה שכבות, וכל בקשת חתימה נבדקת בקפידה:

  • Tokenטוקן אקראי בלתי-ניחושsecrets.token_urlsafe(32), 256 ביט אנטרופיה. אי אפשר "לנחש" קישור של הצעה אחרת.
  • Expiryתוקף מוגבל — לכל קישור יש תאריך תפוגה; אחרי זה הוא ננעל אוטומטית (סטטוס "פג תוקף").
  • CSRFהגנת CSRF ב‑HMAC‑SHA256 — כל שליחת חתימה נושאת חתימת‑אימות חתומה בסוד השרת, ומאומתת בהשוואה בזמן‑קבוע (hmac.compare_digest) כדי למנוע התקפות תזמון.
  • Scopeהרשאה מינימלית — הטוקן פותח בדיוק הצעה אחת, לחתימה בלבד; הוא לא נותן גישה למערכת או לנתונים אחרים.

Is It Admissible

מה נדרש כדי שהחתימה תחזיק בבירור משפטי

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

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

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

ארבעת המאפיינים האלה נשמעים מופשטים, אבל הם מתורגמים לארבעה צעדים מעשיים — בסדר הזה, כי הראשון הוא זה שנותן את רוב הערך והשאר נשענים עליו:

מה החוק דורשמה עושים בפועל
מאפשרת לזהות שינוי במסמך לאחר החתימה מקפיאים את הקובץ ברגע החתימה ושומרים SHA-256 שלו. כל הורדה מגישה את הקובץ הקפוא ולא בונה אותו מחדש.
מאפשרת לזהות מי חתם קוד חד‑פעמי לכתובת או למספר ששמורים ברשומת הלקוח מראש — לא לכאלה שהחותם מקליד באותו רגע.
נוצרה באמצעי בשליטתו הבלעדית הקוד נשלח לערוץ שהחברה הנפיקה, ולא לקישור שאפשר להעביר הלאה.
ייחודית לבעל אמצעי החתימה תיעוד מלא של המסלול — מתי נוצר הקישור, מתי נפתח, מאיזו IP ומאיזה דפדפן — מרוכז לדף אימות אחד.

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

מקפיאים את המסמך ברגע החתימה

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

מאמתים זהות בקוד חד‑פעמי

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

מתעדים את כל מה שקרה בדרך

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

מוסיפים חותמת זמן מגורם שלישי

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

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

1 שליחה קישור ייחודיותאריך תפוגה 2 פתיחה שעה, כתובתומכשיר 3 אימות קוד חד‑פעמילכתובת השמורה 4 חתימה אישור מפורשוהחתימה עצמה 5 הקפאה הקובץ כפי שנחתםו‑SHA‑256 שלו 6 אישרור חותמת זמןמגורם שלישי כל שלב מוסיף שורה לדף אימות החתימה
שלושת המעגלים המודגשים הם מה שחסר במימוש בסיסי: אימות הזהות, הקפאת הקובץ וחותמת הזמן החיצונית. השאר קיים כמעט בכל זרימת חתימה.

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

Why It Matters

מה יצא מזה

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

Build It Yourself

רוצים לבנות את זה? פרומפט להתחלה

העתיקו את הפרומפט הבא ל‑AI (כמו Claude או ChatGPT) כדי לקבל בסיס עובד:

prompt
בנה זרימת חתימה דיגיטלית על מסמך PDF ב־Python / FastAPI:
1. צור endpoint שמפיק לכל מסמך קישור חתימה ייחודי — טוקן אקראי עם secrets.token_urlsafe(32), בעל תאריך תפוגה, שנשמר ב־DB.
2. דף ציבורי /sign/{token} (ללא התחברות) שמציג את המסמך בעברית (RTL), מותאם לנייד, עם משטח חתימה (HTML canvas).
3. צור endpoint לקליטת החתימה: אמת טוקן CSRF חתום ב־HMAC-SHA256 עם סוד השרת (hmac.compare_digest), קבל את החתימה כ־data-URI מה־canvas, סמן את המסמך כ"נחתם" עם חותמת זמן וזהות החותם, והטבע את החתימה ב־PDF.
4. לפני שמאשרים את החתימה, שלח קוד חד־פעמי בן 6 ספרות לכתובת המייל או לטלפון ששמורים ברשומת הלקוח מראש — לא לכאלה שהחותם מקליד. תוקף 10 דקות, 3 ניסיונות, שמור hash של הקוד ולא את הקוד עצמו.
5. מיד לאחר החתימה הקפא את המסמך: שמור את בייטים של ה־PDF כפי שנוצרו ואת ה־SHA-256 שלהם בעמודות signed_pdf_blob ו־signed_pdf_sha256. מכאן ואילך כל מסלול הורדה מגיש את הקובץ השמור ולעולם לא מייצר את המסמך מחדש מהנתונים.
6. תעד כל אירוע בטבלה נפרדת — יצירת הקישור, פתיחתו, אימות הקוד, אישור מפורש בתיבת סימון והחתימה — עם IP, user-agent וחותמת זמן לכל אחד. הפק מהם עמוד "אימות חתימה" וצרף אותו כעמוד אחרון של ה־PDF לפני ההקפאה.
7. שלח את ה־SHA-256 לשירות חותמת זמן חיצוני בתקן RFC 3161 ושמור את ה־token שחוזר לצד המסמך.

Verify It Yourself

שאלות לשאול את ה‑AI כדי לבדוק שהמימוש עומד בדרישות

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

  • 1אם אשנה עכשיו שורה בטבלה של המסמך אחרי שהוא נחתם, ואוריד שוב את הקובץ — האם אקבל בייט אחד שונה? הראה לי את הקוד שמונע זאת.
  • 2מנה לי את כל מסלולי ההורדה של מסמך חתום בקוד הזה. האם כל אחד מהם מגיש את הקובץ השמור, או שיש אחד שמייצר מחדש?
  • 3מאיפה מגיעה הכתובת שאליה נשלח הקוד החד‑פעמי — מרשומת הלקוח או מהבקשה של החותם? הצג את השורה.
  • 4מה קורה אם אותו קישור נפתח משני מכשירים שונים ושניהם מנסים לחתום? ומה אם לוחצים "חתום" פעמיים ברצף?
  • 5איזה מידע נשמר על הרגע שבו נפתח הקישור, ולא רק על רגע החתימה? אם התשובה היא "כלום" — אין דף אימות אמיתי.
  • 6חותמת הזמן שנשמרת — של מי השעון? של השרת שלי, של מסד הנתונים, או של גורם חיצוני?
  • 7אם מסד הנתונים ישוחזר מגיבוי של אתמול, מה עדיין יוכיח שהמסמך שבידי הוא זה שנחתם?

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