דוח חדש של Europol מזכיר לתעשיית הקריפטו שהסיכון הקוונטי אינו אירוע יחיד ואינו פוגע בכל שכבות המערכת באותה צורה. האתגר המעשי הוא לבנות מפת חשיפה, להבין מי יכול להחליף כל מפתח ולתרגל מעבר לפני שהדחיפות מכתיבה את התהליך.
מה Europol באמת אמר
מרכז הסייבר האירופי של Europol פרסם ב־7 באוקטובר 2026 את הדוח Quantum Computing and Cryptocurrencies. האזהרה המרכזית שלו ממוקדת: מחשב קוונטי בעל יכולת מספקת עלול בעתיד לפגוע בקריפטוגרפיית המפתח הציבורי שמשמשת לאישור עסקאות קריפטו. כאשר מפתח ציבורי חשוף, תוקף שיחזיק במכונה ובאלגוריתם המתאימים עשוי, עקרונית, להסיק ממנו את המפתח הפרטי ולחתום על עסקה לא מורשית. הדוח אינו טוען שהבלוקצ׳יין כבר נפרץ, ואינו קובע תאריך שבו הדבר יקרה.
ההבחנה חשובה משום שרשת בלוקצ׳יין משתמשת ביותר מסוג אחד של קריפטוגרפיה. פונקציות hash תומכות במזהי עסקאות, בקישור בין בלוקים ובשלמות הנתונים; חתימות דיגיטליות מוכיחות סמכות על חשבון. Europol מציג את שכבת ה־hash כעמידה יחסית, ומזהה את החתימות והמפתחות הציבוריים החשופים כבעיית ההגירה הדחופה יותר. אם מתייחסים לכל הרכיבים כאילו הם פגיעים באותה מידה, בונים סדר עדיפויות שגוי. השאלה התפעולית הראשונה אינה ״מתי יגיע הקוונטום?״ אלא ״אילו נכסים תלויים באילו מפתחות, וכיצד מחליפים אותם?״
זו בעיית מוכנות בתנאי אי־ודאות. אין כיום ראיה פומבית למחשב קוונטי רלוונטי קריפטוגרפית שמסוגל לבצע את המתקפה בקנה המידה הנדרש לרשת גדולה. אבל אי אפשר להחליף בסוף שבוע ארנקים, חומרה, מדיניות משמורת, חוזים וכללי פרוטוקול. לכן Europol ממליץ על מיפוי, תעדוף, ניהול מפתחות חזק יותר, מעבר מדורג ו־crypto-agility. זהו מודל מוצר ותפעול — לא הימור על מועד פריצת דרך.
החשיפה מתחילה במחזור החיים של המפתח
מודל סיכון שימושי עוקב אחר מפתח מרגע היצירה ועד הפרישה. איזה מכשיר או שירות יצר אותו? איזו סכמת חתימה מגנה עליו? האם המפתח הציבורי כבר הופיע על השרשרת? האם אותו מפתח משמש בכתובות, רשתות או יישומים נוספים? מי רשאי להחליף אותו ואילו אישורים נדרשים? יתרה לבדה אינה מספקת תשובות. שני חשבונות שמחזיקים אותו ערך יכולים להיות ברמות סיכון שונות לחלוטין: אחד ניתן לשדרוג באמצעות smart account מנוהל, ואחר תלוי בבעלים שאינו נגיש ובכלל חתימה קבוע.
גם החשיפה של המפתח הציבורי משתנה לפי הרשת וסוג הכתובת. בחלק מהמערכות הוא מתגלה רק בעת הוצאה; באחרות הוא קיים מלכתחילה או ניתן לשחזור מהחתימה. שימוש חוזר מאריך את חלון החשיפה. משמורת מוסיפה שכבה נוספת: המשתמש רואה יתרה אחת, בעוד שהספק מנהל מפתחות מאוחדים וספר חשבונות פנימי. לכן מלאי הסיכון צריך לכלול רשת, סוג חשבון, סכמת חתימה, מצב חשיפה, מודל משמורת, פעילות אחרונה ומסלול שדרוג — לא רק כתובת וסכום.
היגיינת מפתחות טובה מועילה עוד לפני הגירה פוסט־קוונטית. צמצום שימוש חוזר, אבטחת התקני חתימה, הפרדת תפקידים ובדיקת התאוששות מפחיתים את איומי ההווה ואת איומי העתיד. מוכנות קוונטית אינה תירוץ להזניח phishing, תוכנה שנפרצה, הרשאות זדוניות או בקרה תפעולית חלשה. האיום העתידי חשוב משום שצריך לשלב אותו בתוכנית האבטחה הקיימת, לא להפקיד אותו במסמך מעבדה נפרד.
קודם מלאי, אחר כך אלגוריתם
הפיתוי הוא להתחיל בבחירת אלגוריתם פוסט־קוונטי. זה מוקדם מדי. NIST תקנן שלושה תקנים יסודיים: FIPS 203 להקמת מפתחות ו־FIPS 204 ו־FIPS 205 לחתימות דיגיטליות. אלה נקודות ייחוס חשובות, אך אינן רכיב שאפשר להכניס ללא שינוי לכל ארנק, רשת, חותם חומרה או חוזה. גודל החתימה, עלות האימות, בשלות המימוש ומגבלות הפרוטוקול משתנים. הארכיטקטורה מתחילה בהבנת מה שצריך לעבור.
יש לסווג נכסים לפי חשיבות עסקית וחשיפה טכנית: ארנקי אוצר, נכסי לקוחות, מנהלי bridge, מפתחות שדרוג, שליטת validator או sequencer, חותמי oracle, בעלי חוזים, שומרי חירום, מפתחות גיבוי והרשאות חתימה בענן וב־CI/CD. לכל פריט נדרשים בעלים אחראי, מודל סמכות, הערכת יתרה או השפעה, מצב חשיפה, תלויות ודרך בדוקה לרוטציה. בעלות שאינה ידועה היא עצמה ממצא בעדיפות גבוהה.
התוצאה היא גרף הגירה. Multisig של אוצר עשוי להיות תלוי בחמישה התקני חומרה ובמנוע מדיניות. שדרוג פרוטוקול עשוי לדרוש הצבעת ממשל, timelock ותיאום עם בורסות. לחשבון לקוח רדום ייתכן שאין בעלים שניתן ליצור איתו קשר. Bridge עשוי להישען על קבוצת validators חיצונית. הגרף מראה שסיכון ההגירה כמעט אף פעם אינו נמצא בספריית קריפטוגרפיה אחת; הוא עובר דרך אנשים, ממשקים, ספקים וממשל.
נכסים רדומים הם מקרה הקצה הקשה
משתמש פעיל יכול לעדכן ארנק, להחליף מפתח או לאשר חשבון חדש. נכס רדום אינו יכול. לחלק מהבעלים אבדו פרטי קשר, חלק מהמפתחות שייכים לעיזבונות, חלק מהארגונים נסגרו וחלק מהכספים נמצאים בחוזים ללא מנגנון שדרוג. אלה עלולים להפוך ליעד בולט אם מתקפה תהיה מעשית, אך כל ניסיון להזיז או להקפיא אותם מעלה שאלות קשות של סמכות, בעלות וטעויות זיהוי.
אסור להפוך מוכנות טכנית לטענה שקטה על רכוש של אחרים. הגירה בהסכמה, חוזה הגנה עם השהיה, מסלול התאוששות שאושר בממשל או הגבלה על מפתחות שנחשפו לאחר מועד מסוים — לכל מנגנון השלכות משפטיות וממשליות אחרות. התכנון צריך לקבוע מי רשאי לפעול, איזו ראיה נדרשת, כיצד בעלים מתנגד ואיך מתקנים טעות. אם הדרך היחידה לחזור לאחור היא התערבות שנויה במחלוקת בשרשרת, המגבלה צריכה להיות רשומה כבר עכשיו.
לכן צריך למדוד כיסוי הגירה בנפרד מיכולת הגירה. רשת יכולה לתמוך בחשבון פוסט־קוונטי בעוד שרוב הערך נשאר בכתובות ישנות. משמורן יכול להיות מוכן טכנית בעוד שהסכמות הלקוח והמסמכים אינם מוכנים. לוח המוכנות צריך להציג את האוכלוסייה שאינה מכוסה, ולא להסתפק בכך שקוד חדש קיים.
קיבולת הגירה היא מגבלת מוצר
תכנון בטוח עדיין יכול להיכשל אם הרשת אינה מסוגלת לשאת את המעבר. חתימות ומפתחות פוסט־קוונטיים עשויים להיות גדולים בהרבה מהמקבילות המוכרות מעקומים אליפטיים. הדבר משפיע על גודל עסקה, blockspace, gas, עמלות, זיכרון בארנק חומרה, מגבלות API, indexers ואחסון ארכיוני. קמפיין רוטציה המוני עלול להתחרות בפעילות רגילה בדיוק כשהמשתמשים לחוצים. לכן יש למדל ולתרגל קיבולת, לא להזכיר אותה בהערת שוליים.
צוות המוצר צריך לחשב כמה חשבונות קריטיים ניתן להעביר בכל בלוק, יום ושבוע בתנאים רגילים ובעומס. יש למדל עסקאות כושלות, ניסיונות כפולים, קפיצות עמלה ומשתמש שמתחיל במכשיר אחד ומסיים באחר. הממשק חייב להבהיר יעד והשלכות. הודעה חפוזה של ״אבטחו את הכסף״ יכולה להפוך למכפיל phishing אם אי אפשר להבדיל בין המסלול הרשמי לחיקוי.
תוכנית מדורגת יכולה להתחיל בחשבונות פנימיים בעלי ערך נמוך, לעבור למפתחות תפעוליים שאינם של לקוחות, מדיניות אוצר, הגירת לקוחות מרצון ולבסוף חשבונות בעלי תלות גבוהה. בכל שלב נדרשים מגבלות, ניטור, קיבולת תמיכה וכלל עצירה או rollback. מטרת הפיילוט היא לבדוק אם כל המערכת — חוזים, ארנקים, תמיכה, ציות, ניטור ותקשורת — מסוגלת לעבור יחד.
בתקופת החפיפה נוצרים סיכונים חדשים
למשך תקופה, שיטות קלאסיות ופוסט־קוונטיות יחיו זו לצד זו. חתימה היברידית עשויה להפחית תלות ברכיב יחיד, אך גם מוסיפה מורכבות. איזו חתימה קובעת אם אחת עוברת והשנייה נכשלת? האם תוקף יכול לכפות downgrade למסלול הישן? האם מפתחות התאוששות מוגנים כמו המפתח היומיומי? האם smart account ממשיך לקבל חותם legacy לנצח משום שענף חירום לא בוטל? לוגיקת המעבר יכולה להפוך לפגיעות שהיא נועדה לפתור.
ניהול גרסאות, domain separation, הגנת replay ומועדי ביטול מפורשים הם דרישות מוצר. ארנק צריך לדעת לא רק שהחשבון תומך post-quantum אלא איזו מדיניות פעילה בגובה בלוק מסוים. Indexer חייב להבין את שני הפורמטים. בורסה ומשמורן צריכים לזהות כללי הפקדה ומשיכה חדשים. מערכת הניטור צריכה להבדיל בין עסקת הגירה לגיטימית לבין תנועה לא מורשית.
NIST מגדיר crypto-agility כיכולת להחליף או להתאים אלגוריתמים קריפטוגרפיים בפרוטוקולים, יישומים, תוכנה, חומרה ותשתית תוך שמירה על אבטחה והמשך פעולה. הסיום הוא העיקר: ארגון שמסוגל להחליף אלגוריתם רק באמצעות עצירת משיכות, בנייה מחדש של כל לקוח ובקשה מהמשתמשים לסמוך על תהליך מאולתר אינו agile. הוא רק הוכיח שאפשר להשתנות בזמן משבר.
משמורנים ובורסות הופכים למתאמי הגירה
לספקים גדולים יש יתרון משום שהם יכולים לסובב מפתחות מאוחדים, לעדכן מדיניות חשבון ולתקשר עם משתמשים רבים. הם גם מרכזים סיכון תפעולי. הקפאה חד־צדדית וחפוזה עשויה להגן על נכסים ובו בזמן למנוע גישה לגיטימית; תגובה מאוחרת עלולה להשאיר מפתחות חשופים. נדרשים ספים שאושרו מראש לאזהרות, אימות מוגבר, בקרת משיכות ופעולות חירום, יחד עם סקירה משפטית ותמיכת לקוחות.
תפקיד הספק אינו מסתכם בארנקים שלו. כתובות הפקדה, sweeping, אחסון חם וקר, שירותי חתימה, Travel Rule, סינון סנקציות, proof of reserves וכלי תגובה לתקרית עשויים להסתמך על הנחות לגבי כתובות וחתימות. בדיקת הגירה צריכה לעקוב אחר עסקה מהמשתמש, דרך הניטור והסליקה, ועד החשבונאות והייצוא. Unit test קריפטוגרפי בודק רק חוליה אחת.
תקשורת היא חלק מהאבטחה. הודעה צריכה להסביר מה ידוע, מה לא ידוע, מי נדרש לפעול ובאילו ערוצים רשמיים. עליה להימנע משעון עצר שאינו מבוסס על ראיות. צוותי תמיכה צריכים תסריטים למכשיר שאבד, עיזבון, חשבון תאגידי משותף ומשתמש באזור מוגבל. הגירה נכונה טכנית שהמשתמש אינו מסוגל להשלים בבטחה אינה הגירה שלמה.
מודיעין בלוקצ׳יין צריך להפוך גם לצופה קדימה
רוב מודיעין הבלוקצ׳יין מתאר את העבר: כתובת שלחה ערך, פגשה שירות או הצטרפה לאשכול. מוכנות קוונטית מוסיפה שכבה צופה קדימה. יש למפות באילו חשבונות נחשף מפתח ציבורי, כמה זמן הוא חשוף, על איזו יתרה או סמכות הוא שולט, האם קיים מסלול שדרוג וכמה מהר אפשר להבדיל בין תנועה לגיטימית לגניבה. זו מפת חשיפה, לא מפת האשמות.
התוויות חייבות להיות מדויקות. ״מפתח ציבורי נצפה״ הוא נתון מהשרשרת. ״אין מסלול הגירה ידוע״ הוא ניתוח טכני. ״לא ניתן להגיע לבעלים״ עשוי להגיע מרישום ספק. ״יעד קוונטי סביר״ הוא תחזית עם הנחות. אף תווית אינה מוכיחה בעלות, כוונה או עבירה. מוצר אחראי מציג מקור, זמן ורמת ביטחון לכל אחת, ומאפשר לעדכן את ההערכה בלי לשכתב את התצפית המקורית.
רשימות ניטור יכולות להתמקד בסמכויות בעלות השפעה: מנהלי bridge, מפתחות שדרוג ויתרות רדומות גדולות. התראות צריכות לזהות שינוי מצב — חשיפה ראשונה, חתימת legacy בלתי צפויה, מעבר לחשבון חדש, תנועה אחרי תרדמת ארוכה או עקיפת תהליך ההגירה. החקירה מתחילה באימות. אין להניח שכל תנועה חריגה היא אירוע קוונטי כאשר גניבת מפתח רגילה עדיין סבירה הרבה יותר.
רציפות ראייתית מתחילה לפני האירוע
יכולת עתידית לזייף חתימה לא תהפוך אוטומטית כל עסקה היסטורית למזויפת. הזמן, ההכללה בבלוק, הקונצנזוס ומצב הטכנולוגיה באותו מועד יישארו ראיות. אבל חוקרים יצטרכו להסביר אילו הנחות אימות חלו כאשר העסקה בוצעה והאם היה סביר שהמפתח כבר נפגע. לשם כך צריך לשמר מידע היום.
מערכות תיק צריכות לשמור עסקאות גולמיות, headers של בלוקים, מזהי רשת, קוד חוזה או הפניה למקור מאומת, גרסאות parsing ושיטת אימות חתימה. צילום מסך ודוח ספק אינם מספיקים. כאשר תיוג או אשכול חשובים, צריך לשמור מקור וזמן. אם הגירה פוסט־קוונטית מעבירה נכס לחשבון חדש, יש לתעד את הקשר בין הסמכות הישנה לחדשה כך שניתן יהיה לבקר אותו בעתיד בלי לחשוף מידע אישי מיותר.
אותה משמעת מגנה גם על בעלים לגיטימיים. אם בעתיד ארגון יחלוק על העברה, האנליסט יצטרך להפריד בין תצפית על השרשרת לבין הסקה לגבי החותם. שימור שרשרת הפרשנות מונע מאי־ודאות קריפטוגרפית עתידית להפוך כל רישום ישן לוויכוח שאי אפשר לפתור.
לוח מדדים מעשי למוכנות
הנהלה וצוות מוצר אינם צריכים ציון קוונטי יחיד בצבע אדום, צהוב או ירוק. הם צריכים כמה שאלות מדידות: איזה אחוז מהנכסים וסמכויות החתימה הקריטיים מופיע במלאי? באיזה חלק נחשף מפתח ציבורי? כמה חשבונות יכולים להחליף מפתח ללא שינוי פרוטוקול? מהי קיבולת ההגירה תחת עמלות גבוהות? לכמה משתמשים ניתן להגיע ולסייע? האם ההיסטוריה והראיות שורדות את המעבר?
לכל מדד נדרשים בעלים ותאריך בדיקה. כיסוי מלאי ללא ראיה הוא אופטימי; חשבון שמסומן כניתן לשדרוג צריך להשלים חזרה. קיבולת הגירה צריכה להגיע מ־testnet או מניסוי ייצור מבוקר, לא רק מחישוב גודל חתימה. נגישות משתמשים צריכה לכלול הודעות שחזרו וחשבונות שאינם נגישים. רציפות ראייתית צריכה להיבדק באמצעות שחזור תיק מדגמי בפורמט הישן והחדש.
לוח המדדים צריך לרשום גם תלויות: בשלות תקן, תמיכת חומרה, גרסאות לקוח, הצבעות ממשל, משמורנים חיצוניים והחלטות רגולטוריות. תלות אינה תירוץ להמתנה. היא מצביעה היכן לבנות חלופה, לדרוש התחייבות או ליצור fallback. המטרה היא להחליף תאריך שאי אפשר לדעת בתוכנית עבודה שאפשר לראות.
Runbook צריך להיכתב לפני הדחיפות
ה־runbook מתחיל בטריגרים. עדכון תקן, תוצאה קריפטואנליטית אמינה, אבן דרך בחומרה, advisory של ספק או מתקפה שנצפתה מצדיקים רמות תגובה שונות. לכל טריגר צריך להיות מעריך מוגדר וסף ראייתי. ספקולציה ברשת חברתית לא צריכה להפעיל אוטומטית בקרות חירום, אך אסור גם לחכות לגניבה מאומתת לפני כינוס הצוות.
השכבה הבאה מגדירה פעולות: להגביר ניטור, לסובב מפתחות נבחרים, להגביל יצירת חשבונות legacy חדשים, לפתוח הגירה מרצון, להרחיב תמיכה, להשהות פעולה פגיעה או לתאם שדרוג פרוטוקול. לכל פעולה נדרשים סמכות, היקף, משך, תקשורת למשתמש ודרך ביטול. תרגיל שולחן צריך לכלול הנדסה, משפט, ציות, תקשורת, תמיכה והנהלה, משום שהאירוע האמיתי לא יישאר בתוך צוות הפיתוח.
לבסוף נדרשת לולאת למידה. אחרי כל תרגיל יש לתעד זמן זיהוי, זמן החלטה, שיעור הצלחת הגירה, עומס תמיכה, התראות שווא וחשבונות שלא נפתרו. מעדכנים את המלאי ואת ההנחות. מוכנות קוונטית אינה מסמך ציות חד־פעמי; היא היכולת לבצע שינוי קריפטוגרפי בלי לאבד שליטה תפעולית.
מוכנות אינה פאניקה
המסקנה החזקה מדוח Europol אינה שכל מחזיק צריך להזיז כסף היום. המסקנה היא שהמתנה לוודאות תהיה כשל ניהולי שניתן למנוע. מעברים קריפטוגרפיים איטיים משום שקוד, חומרה, ממשל, זכויות קניין והתנהגות אנושית נעים במהירויות שונות. העבודה שאפשר לעשות עכשיו — מלאי, היגיינת מפתחות, בחינת תקנים, בדיקת קיבולת, שימור ראיות וסמכות ברורה — מועילה גם אם לוח הזמנים הטכנולוגי משתנה.
מנקודת המבט של דור ארד, זהו מבחן איכות מוצר. תשתית קריפטו בוגרת צריכה לדעת אילו הנחות מגנות על כל נכס, מי רשאי לשנות אותן וכיצד המשתמש נשאר בטוח בזמן השינוי. מודיעין בלוקצ׳יין צריך להציג חשיפה בלי להפוך תחזית להאשמה. ממשל צריך להכין אפשרויות הגנה בלי להתייחס לרכוש רדום כחסר בעלים. אבטחה צריכה לתקשר אי־ודאות בלי להסתתר מאחוריה.
הסיכון הקוונטי אינו שעון עצר. הוא מועד אחרון שאין לו תאריך ידוע, והגירה שיש לה משימות ידועות רבות. ארגון שיתחיל אותן עכשיו יוכל להגיב במידתיות ככל שהראיות יתפתחו. מי שידחה אותן עלול לגלות שהבעיה הקשה לא הייתה בחירת האלגוריתם, אלא מציאת כל מפתח, תיאום כל תלות והעברת האמון בלי לשבור אותו.