تصور کنید دنیایی را که در آن اثبات اصالت یک فایل دیجیتال، بهجای یک سرویس اجارهای، شبیه به آب و برق یک ابزار عمومی و رایگان باشد. پروژه Let's Seal با معرفی استاندارد SEAL (مدارک مهرشده متصل به دفتر کل)، اکنون به هر کسی اجازه میدهد هر نوع فایلی را بهصورت رمزنگاریشده و رایگان مهر کند تا سلامت و منشأ آن برای همیشه قابل تأیید باشد، بدون آنکه نیاز باشد به یک مرجع مرکزی پولی تکیه کند. این استاندارد جهانی بهگونهای طراحی شده است که تضمین کند یک اثر مهرشده تنها یک روش واحد برای بررسی داشته باشد و هر کسی در هر زمان بتواند آن را بازبینی کند و برای همیشه معتبر باقی بماند. طبق اعلام تیم توسعه، از آنجایی که این یک استاندارد باز است، کاربران میتوانند با هر ابزار سازگار مهر بزنند و با هر ابزار دیگری آن را تأیید کنند. پروژه Let's Seal نه تنها این استاندارد را خلق کرده، بلکه شبکه رایگان و پیادهسازی مرجع آن را نیز مدیریت میکند که وظیفه صدور و تأیید مهرها را بر عهده دارد؛ در واقع این استاندارد ستون فقرات پروژه است و هر آنچه در این پروژه ساخته شده، بر پایه آن است و بهصورت رایگان در اختیار همگان قرار گرفته است.
تا پیش از این، امضاهای دیجیتال در فرمتهای مختلف پراکنده بودند و شرکتهای بزرگ هزینههای گزافی برای آنها میگرفتند. بیشتر کاربران در حال حاضر مجبور هستند از ابزارهای اختصاصی (Proprietary) استفاده کنند که آنها را در اکوسیستم یک فروشنده خاص برای تأیید اعتبار محبوس میکند. Let's Seal با عرضه پیادهسازی مرجع خود قصد دارد این چرخه وابستگی را بشکند و خود را بهعنوان «Let's Encryptِ اثبات اسناد» معرفی کند. درست همانطور که Let's Encrypt گواهنامههای TLS پولی را منسوخ کرد و دسترسی به وب امن را رایگان ساخت، Let's Seal میخواهد مهرهای پولی اسناد را به تاریخ بسپارد و آنها را منسوخ کند.
زمینه و بنیاد (Context and Foundation)
این پروژه بهجای مدل استارتاپی، بهعنوان یک پروژه با سود عمومی تحت یک بنیاد فعالیت میکند. این ساختار سازمانی تضمین میکند که اصالت فایلها بهعنوان یک زیرساخت باقی بماند و نه محصولی برای اجاره، و همچنین تضمین میکند که استاندارد SEAL هرگز نتواند دوباره پشت یک دیوار پرداخت (Paywall) قرار گیرد. تمام موتور پردازشی، SDKها و خودِ استاندارد تحت لایسنس Apache-2.0 متنباز هستند تا هر کسی بتواند از آنها استفاده کند.
در این دیدگاه، اصالت بهعنوان یک زیرساخت حیاتی (Essential Infrastructure) تعریف شده است. با رایگان، باز و بنیاد-محور کردن این سیستم، پروژه موانع مالی و وابستگی به فروشندگان (Vendor Lock-in) مرتبط با مهر زدن سنتی اسناد را حذف کرده است. این سیستم بهگونهای طراحی شده که مسدود کردن آن غیرممکن باشد، زیرا مشخصات فنی SEAL منتشر شده و برای هر کسی که بخواهد بهطور مستقل آن را پیادهسازی کند، رایگان است.
تثلیث رمزنگاری (The Cryptographic Trifecta)
هر اثبات SEAL سه مورد مشخص را بهصورت رمزنگاریشده تثبیت میکند و مرزهای خود را بهوضوح بیان مینماید:
- یکپارچگی (تغییرناپذیری): تضمین میکند فایل حتی یک بایت تغییر نکرده است. اگر تنها یک بایت از فایل تغییر کند، امضا میشکند و نامعتبر میشود.
- زمان: اثبات میکند که فایل در تاریخ مشخصی وجود داشته است. این مورد از طریق OpenTimestamps به بلاکچین بیتکوین متصل (Anchor) میشود؛ این بدان معناست که نیازی نیست کاربر برای تأیید زمان به اپراتور Let's Seal اعتماد کند، بلکه اعتماد به شبکه بیتکوین است.
- هویت (صادرکننده): مهر، گواهینامه خاص مورد استفاده را شناسایی میکند. در صورتی که یک سازمان کنترل یک دامنه را (از طریق رکورد DNS یا ارسال پیام به یک آدرس کنترلکننده) ثابت کرده باشد، مهر شامل آن دامنه بهعنوان یک هویت ماشین-خوانده (dNSName) میشود.
باید توجه داشت که اثبات SEAL بهمعنای گواهی رسمی قانونی (Notarization) نیست و هویت قانونی فرد در دنیای واقعی را ادعا نمیکند. ویژگی هویت در اینجا بهطور مشخص یک ایمیل تأییدشده توسط ارائهدهنده را به سند متصل میکند، که این دقیقترین عبارت برای توصیف خدماتی است که این سیستم ارائه میدهد.
سازگاری جهانی با فایلها و فرمتها
برخلاف مهرهای اختصاصی، استاندارد SEAL اثباتها را بهصورت بومی (Native) در فرمتهای مختلف جای میدهد تا هر اعتبارسنج استاندارد بتواند آنها را بررسی کند. برای خواننده نیازی به ابزارهای سفارشی نیست و هیچ وابستگی به Let's Seal برای مرحله تأیید وجود ندارد. یک PDF مهرشده همچنان یک PDF معمولی است که در هر جایی باز میشود و یک تصویر مهرشده همچنان در همه جا نمایش داده میشود.
سازگاری با فرمتها به شرح زیر است:
- PDFها: استفاده از امضاهای PAdES / X.509 تعبیه شده در فایل. اینها توسط هر اعتبارسنج استاندارد PAdES یا اعتبارسنج مرجع پروژه قابل بررسی هستند.
- رسانهها (تصویر، ویدیو، صوت): بهرهگیری از مانیفستهای C2PA (اعتبارنامههای محتوا) تعبیه شده در رسانه، که توسط هر خواننده C2PA قابل تشخیص است.
- فایلهای XML: استفاده از امضاهای Enveloped W3C XML-DSig که توسط هر اعتبارسنج XML-DSig قابل تأیید است.
- ایمیلها: بهکارگیری فرمتهای S/MIME multipart/signed طبق استاندارد RFC 8551 که از طریق دستور
openssl smime -verifyقابل تأیید است. - سایر فایلها: استفاده از فایلهای جداشده (Detached) CAdES / CMS با پسوند
.sigبر روی هش SHA-256 فایل اصلی. در این فرآیند، بایتهای فایل اصلی هرگز از دستگاه کاربر خارج نمیشوند و تأیید آن از طریقopenssl cms -verifyامکانپذیر است. - آثار نرمافزاری: یکپارچهسازی امضاها با گواهیهای in-toto / DSSE برای SBOM (صورتحساب مواد نرمافزاری) و منشأ SLSA، با استفاده از ابزارهای استاندارد امضای آثار نرمافزاری که در اکثر خطلولههای (Pipelines) تولید موجود است. این رویکرد برای ایمنسازی زنجیره تأمین نرمافزار مشابه efforts است که در روشهای جدید تزریق شفاف اعتبارنامه برای عاملهای هوش مصنوعی دیده میشود تا از اعتبار منشأ دستورات اطمینان حاصل گردد.
شفافیت و قابلیت حسابرسی
برای جلوگیری از جعل هویت و جعل اسناد، هر مهر در یک دفتر کل شفاف (Transparency Log) عمومی و فقط-خواندنی بر اساس RFC 6962 ثبت میشود. این دقیقاً همان ساختاری است که مرورگرها برای شفافیت گواهینامهها (Certificate Transparency) به آن تکیه میکنند. ریشه (Root) این دفتر کل امضا شده و به بیتکوین متصل گشته تا سوابقی دائمی و غیرقابل تغییر از آنچه مهر شده است ایجاد شود.
این معماری به هر کسی اجازه میدهد بدون نیاز به داشتن حساب کاربری، دو بررسی مستقل انجام دهد:
- اثبات شمول (Inclusion Proofs): هر کس میتواند ثابت کند یک مهر خاص در دفتر کل وجود دارد. این کار با دریافت اثبات از مسیر
/api/log/proof?sha256=<hex>و بررسی آن در برابر سر-درخت امضا شده در مسیر/api/log/sthانجام میشود. - اثبات سازگاری (Consistency Proofs): این اثباتها در مسیر
/api/log/consistencyدر دسترس هستند تا ثابت کنند دفتر کل فقط بهصورت افزایشی (Append-only) بوده و هرگز بازنویسی نشده است.
اگر گواهینامهای برای مهر زدن سندی با نامی استفاده شود که نباید داشته باشد، شواهد بهصورت عمومی و دائمی ثبت میماند. این مدل یک مسیر حسابرسی برای جعل هویت ایجاد میکند که در آن سوءاستفادهها قابل گزارش هستند و صادرکنندگان متخلف میتوانند تعلیق شوند؛ این کار باعث میشود کلیدهای آنها متوقف شده و نشان تأیید (Verified Badge) آنها حذف شود. این مدل دقیقاً مشابه نحوه مدیریت TLS در وب از طریق کنترل دامنه است.
روشهای پیادهسازی و دسترسی
پروژه Let's Seal سه روش مجزا و رایگان برای مهر کردن فایلها ارائه میدهد:
۱. وباپلیکیشن میزبانیشده: در آدرس app.letsseal.org در دسترس است. این برنامه در مرورگر کار میکند و نیازی به نصب ندارد. کاربران میتوانند فایلها را مهر کنند، اسناد را برای امضا (بهصورت دورکار، حضوری یا بدون ایمیل) ارسال کنند و اعتبارنامههای برندشده صادر نمایند.
۲. خط فرمان (CLI) و API: ابزار sealbot برای ترمینالها، به همراه یک REST API و SDKهایی برای یکپارجهسازی فرآیند مهر زدن در سیستمهای موجود.
۳. میزبانی شخصی (Self-Hosted): کاربران میتوانند کل موتور پردازشی را تحت گواهینامه صادرکننده (CA) خود اجرا کنند. این شامل کد CA (ca/)، سرویس امضای FastAPI (signing-service/) و داشبورد وب Next.js (web/) است.
برای توسعهدهندگان، REST API طیف گستردهای از نقاط دسترسی (Endpoints) را ارائه میدهد: /api/v1/seal برای PDFها، /api/v1/seal/c2pa برای رسانهها، /api/v1/seal/xml برای XML، /api/v1/seal/smime برای ایمیلها و /api/v1/seal/detached برای مهرهای مبتنی بر هش. نقاط دسترسی تکمیلی شامل /api/v1/seal/blob برای آثار نرمافزاری، /api/v1/seal/identity برای ایمیلهای تأییدشده، /api/v1/attest برای SBOM/SLSA، /api/v1/anchor برای اتصال به بیتکوین و /api/v1/verify برای تأیید عمومی است.
جزئیات: گردش کار فنی و تأیید (Details)
تأیید اصالت همواره رایگان است و میتواند بهصورت کاملاً آفلاین انجام شود. یک مهر هر آنچه برای بررسی نیاز است را در خود جای داده است. برای تأیید آفلاین، کاربر تنها باید اثرانگشت ریشه منتشرشده را پین (Pin) کند:SHA-256: 02:68:6D:EE:20:67:31:C4:59:C1:7A:9F:58:36:7B:0B:0B:BA:5D:24:C6:85:D8:6D:1F:74:49:86:2D:C0:FE:BE
این اثرانگشت، موضوع CN=Let's Seal Root CA, O=Let's Seal, C=GB را شناسایی میکند. این Root CA از آدرس letsseal.org/api/root-ca قابل دانلود است.
مکانیزمهای تأیید بر اساس فرمت:
- PDF: استفاده از اعتبارسنج استاندارد PAdES با ریشه پین شده، یا اجرای دستور
python spec/verify.py sealed.pdf sealed.pdf.ots. - ایمیل/جداشده: دستور
openssl smime -verify -in message.eml -CAfile letsseal-root.crtیاopenssl cms -verify -inform DER -in file.sig -content file -binary -CAfile letsseal-root.crt. - نرمافزار/SBOM: استفاده از ابزارهای استاندارد و باز امضای آثار نرمافزاری در برابر ریشه منتشر شده.
- زمان: استفاده از دستور
ots verify sealed.pdf.otsدر برابر شبکه بیتکوین.
یک حکم نهایی (Verdict) به زبان ساده برای یک سند مهرشده (مثلاً contract.pdf) شامل موارد زیر است:
- هش سند: مقدار SHA-256 که دقیقاً با بایتهای مهرشده مطابقت دارد (مثلاً
9f2c1a…e7b4). - صادرکننده: مثلاً «Acme Solicitors LLP» که نشان میدهد آنها کنترل دامنه
acme.exampleرا دارند (dNSName). - برچسب زمانی: مثلاً «۱۴ ژوئیه ۲۰۲۶ ساعت ۱۱:۴۲ UTC»، متصل به بلوک شماره ۸۱۲,۰۴۳ بیتکوین از طریق OpenTimestamps.
- شفافیت: ورودی شماره ۴۸,۱۲۰ در دفتر کل عمومی با یک اثبات شمول معتبر.
این حکم بهطور سختگیرانه تعریف شده است: اصیل (Authentic) = معتبر و دستنخورده و مورد اعتماد. یک امضای رمزنگاریشده که معتبر است اما به ریشه پین شده متصل نمیشود، بهعنوان «شناختهنشده» (Unrecognised) گزارش میشود و هرگز «اصیل» نامیده نمیشود تا از هرگونه بردار جعل جلوگیری شود.
اثرات استراتژیک و موارد کاربرد
با تبدیل اصالت به یک زیرساخت، Let's Seal قدرت را از فروشندگان امضای سند به کاربران بازمیگرداند. وقتی اثبات «همراه» با فایل حرکت میکند (Rides along)، وابستگی به شرکت صادرکننده برای تأیید اعتبار از بین میرود. این امر باعث میشود سرویسی که پیشتر منبع درآمدی با حاشیه سود بالا برای شرکتهای حقوقی و امنیتی بود، به یک کالای عمومی تبدیل شود.
این استاندارد برای هر بخشی طراحی شده و راهنماهای کاربردی و اثباتهای زنده برای موارد زیر ارائه میدهد:
- حقوق و امور مالی: انتقال ملک، منابع انسانی شرکتی، بانکداری، وامدهی، بیمه، حسابرسیهای حسابداری، مدیریت سرمایهگذاری و گزارشهای نقشهبرداری.
- زنجیره تأمین: تولید، تجارت، تدارکات و امنیت زنجیره تأمین نرمافزار.
- حوزههای رگوله شده: بهداشت و درمان، داروسازی و علوم زیستی، مهندسی ساختمان، مالکیت معنول و مدارک تحصیلی.
- رسانه: روزنامهنگاری، آثار خلاقانه و فریلنسرهای مستقل.
در حالی که محتوای تولید شده توسط هوش مصنوعی و جعلهای عمیق (Deepfakes) باعث میشود منشأ دیجیتال (Provenance) حیاتی شود، داشتن روشی رایگان و مبتنی بر استاندارد باز برای اتصال فایلهای واقعی به یک بلاکچین، یک خط دفاعی ضروری برای اعتماد ایجاد میکند. تغییر به سمت هویت مبتنی بر کنترل دامنه، نیاز به تأیید هویتهای حقوقی پیچیده برای اثباتهای اولیه اصالت را از بین میبرد.
معماری و ابزارهای توسعهدهنده
موتور پردازشی این سیستم کاملاً قابل میزبانی شخصی است و هیچ کد اختصاصی برای نسخه میزبانیشده وجود ندارد. یک نصب تککاربره دقیقاً همان کدی را اجرا میکند که در سرویس میزبانی شده اجرا میشود. توسعهدهندگان میتوانند از CLI sealbot (نصب از طریق npm i -g sealbot یا npx sealbot) استفاده کنند که شامل دستوراتی مثل seal (مهر زدن)، verify (تأیید)، issue (صدور)، anchor (اتصال) و watch (رصد) است.
ساختار مخزن (Repository Layout):
ca/: مدیریت گواهینامهها بهعنوان کد برای صدور ریشه و گواهینامههای میانی.signing-service/: سرویس امضای FastAPI که کلید میانی را نگه میدارد.web/: اپلیکیشن Next.js شامل داشبورد، API و پورتال تأیید.spec/: مشخصات فنی SEAL و اعتبارسنج مرجع.sdk/: کلاینتهای دستنویس برای Python و TypeScript، بهعلاوه طرح OpenAPI.cli/وcli-rs/: ابزار sealbot در زبانهای Node.js و Rust.ci/: GitHub Action برای مهر زدن آثار نرمافزاری در خطلولههای CI.
برای مشاهده استاندارد در عمل، میتوانید اعتبارسنج مرجع را بهصورت محلی با دستور python spec/verify.py sealed.pdf sealed.pdf.ots اجرا کنید یا از پورتال تأیید عمومی در verify.letsseal.org استفاده نمایید. مأموریت این پروژه شفاف است: اثبات واقعی بودن یک فایل، یک خیر عمومی (Public Good) است و باید متعلق به تمام کسانی باشد که به آن تکیه میکنند.
گام بعدی شما
- اگر مدارک دیجیتالی حساس دارید، از وباپلیکیشن
app.letsseal.orgبرای مهر کردن رایگان آنها استفاده کنید. - توسعهدهندگان میتوانند
sealbotرا نصب کرده و فرآیند تأیید اصالت فایلها را در خطلولههای (Pipeline) CI/CD خود ادغام کنند. - برای اطمینان از عدم جعل، اثرانگشت Root CA را در سیستم خود ذخیره کنید تا تأییدات را کاملاً آفلاین انجام دهید.
اما داستان سختافزاری این تحول و نحوه پردازش هشها در مقیاس بالا حتی شگفتانگیزتر است — به تحلیل ما درباره بهینهسازیهای L1 در بلاکچین مراجعه کنید.
گفتگو