لایب سان

6 I. Grishkov et al. Fig. 1. Self-encryption process, adopted from [11] 3 Background Original implementation of the self-encryption schema by David Irvine [11] was modified and used for this research. The use of rayon library (which adds paral- lelization to the code) was removed from the algorithm, due to the fact that the compilation target (WebAssembly) only supports single-threaded code. Addi- tionally the code base was modified to include an interface for communication with the external code. Changes were also done to the Cargo.toml to make the code compatible with the target. Modified self-encryption algorithm was com- piled to WebAssembly and run in a virtual machine (VM) and invoked from the code of the developed local application (which allows the interaction with the Hyperledger Fabric Smart Contract). A more detailed description of the pro- cess will be given in the Sect. 4. The benchmarks of this implementation will be provided in Sect. 5. Hyperledger Fabric test network v2.4.3 was used. Test network was deployed to Docker based on the tutorials provided by Hyperledger Fabric2. Smart contract was then deployed (detailed in Sect. 4). Encrypted file storage is handled by the IPFS, which is a distributed Torrent database, which uses hashes of files to address its content. IPFS node was also deployed to Docker. For IPFS deployment two directories (staging and data) were 2 Usage of the command requires navigating to the root directory of the test-network, provided by the Hyperledger Fabric [8]. ID-Based Self-encryption via Hyperledger Fabric Based Smart Contract 7 mounted on the host file system to persist the stored data, when the container is stopped. Hyperledger Fabric provides official software development kit (SDK) for 3 languages: Go, Java, Javascript. Go was chosen for implementation of the project, due to ease of integration with both Hyperledger Fabric and the IPFS. Encryption library is written in Rust and is compiled to WebAssembly, hence a way to call WebAssembly was needed. Go also provides support for Wasmer library that allows to call WebAssembly function directly from Go code. 4 ID-Based Self-encryption 4.1 Integrating Identity into the Encryption This paper offers an extension to the algorithm proposed by Irvine [9]. Encryp- tion step in the original algorithm is modified to include identity of a person who is running the algorithm into the encryption process. Instead of using part of the chunk hash as a key for AES 128, the result of XoR of the hashed iden- tity and the chunk hash is used as a key. The identity can be any string of any length. If the length of this string is shorter than the length of the key, then the cycle function is applied to the string, which repeats the iterator of a string. The hashing function SipHash 1-3 is used to hash the identity of a user, before passing it to the XoR function. Figure 2 demonstrates the process of encrypting a file using the modified version of self-encryption with identity integrated into the encryption process. Fig. 2. ID-based self-encryption process 8 I. Grishkov et al. Decryption of the file, that was encrypted using ID-based self-encryption, is similar to that of a regular self-encryption, with the key for AES 128 being the only different part. The decryption calculates the key the same way the encryption does it by applying XoR function to the hash of identity and the chunk hash from the data map. The implementation of the encryption scheme can be found on GitHub3. 4.2 Connecting the Encryption Algorithm and the Local Application The implementation of the identity-based self-encryption is written purely in Rust, while the client application is written in Go. This creates a demand for a way to integrate Rust library into Go code. Among the solutions to tackle the problem are: 1. Use Go tools to assemble the Go code and compile Rust code into a static library. Then link compiled code using additional assembly “glue-code” [17]. 2. Compile Rust to a static library and call it from the Go code using Go build-in pseudo-library C for interacting with native interfaces. 3. Compile Rust to WebAssembly (WASM) code and call it from Go using Wasmer library4. All of the methods have been successfully tried. The first two methods do not allow cross compilation, because both of them require compiling Rust to a static library, which is platform-specific. Additionally, the first methods requires the use of assembly language, which is different on different processor architectures and operating systems. The second method also uses C pseudo-library, which does not allow cross-compilation of the Go code. Overall, both methods are very platform-specific, which makes them less preferable choice. The third method was chosen for connecting Rust library to Go code. Com- piling Rust to WASM to use as a standalone application or a library, can be done using the following command: $ c a r g o b u i l d −−t a r g e t =[ c h o s e n t a r g e t ] where chosen target is a WebAssembly target that can be either wasm32- unknown-unknown or wasm32-wasi. The latter was used, because it compile using WASI API5, which is a system API that provides access to multiple oper- ating system functionalities, such as access to the file system. The resulting WASM file is then placed in a hidden folder in the home direc- tory of a user, so it can later be loaded by the Go code. As the WASM code is used within a virtual machine (VM), it’s independent from the operating system it will run on, so requires compiling only for one target. 3 https://github.com/ilyagrishkov/ib-self-encryption-rust. 4 https://wasmer.io/. 5 https://wasi.dev/. ID-Based Self-encryption via Hyperledger Fabric Based Smart Contract 13 is in Go), the execution time can differ when Rust functions are called from Go compared to pure Rust execution time. Files of sizes 100-, 250-, 500-, 750 kilobytes, 1 megabyte, 10-, 25-, 50-, 75-, and 100 megabytes were created for benchmarking both the pure Rust implementa- tion as well as the WASM + Go implementations. Moreover, for this benchmark both the Rust code and the WASM library were optimized using maximum level of optimization provided by the Rust compiler. Fig. 5. Dependence of the execution time of id-based self-encryption algorithm in pure Rust from the file size The initial benchmark was performed on the encryption function only and was measuring execution time of the pure Rust implementation. Figure 4 shows the results of the benchmarking. The chart show near-linear dependence between the size of the file and the time it takes to encrypt it. This dependence can be explained by the fact that the most demanding computational is the AES 128 encryption process and with the increase of the file size, then number of chunks it is split to increases. Each chunk of the original file needs to be individually encrypted, hence the computation time grows linearly with the size of the file. As the encryption function execution time grows linearly due to the com- putational demand of the AES 128 and the hashing algorithms, the decryption process will be identical, because it uses the same algorithms for decryption. In order to achieve more objective benchmark results, file of each size has been encrypted 100 times and the average calculated. In order to visualize execution time a chart in Python using MatPlotLib8 was created. The chart contains a 25- bin histogram, each representing density of a particular measurement. Follow

چکیده فارسی

6 I. Grishkov et al. شکل 1. فرآیند رمزگذاری خود، اتخاذ شده از [11]. 3 پس زمینه اجرای اصلی طرحواره رمزگذاری خود توسط دیوید ایروین [11] اصلاح شد و برای این تحقیق استفاده شد. استفاده از کتابخانه rayon (که موازی سازی را به کد اضافه می کند) از الگوریتم حذف شد، زیرا هدف کامپایل (WebAssembly) فقط از کدهای تک رشته ای پشتیبانی می کند. علاوه بر این، پایه کد به گونه ای اصلاح شد که یک رابط برای ارتباط با کد خارجی را شامل شود. همچنین تغییراتی در Cargo.toml انجام شد تا کد با هدف سازگار شود. الگوریتم خود رمزگذاری اصلاح شده در WebAssembly کامپایل شد و در یک ماشین مجازی (VM) اجرا شد و از کد برنامه محلی توسعه‌یافته (که امکان تعامل با قرارداد هوشمند Hyperledger Fabric را فراهم می‌کند) فراخوانی شد. شرح مفصل تری از این فرآیند در بخش داده خواهد شد. 4. معیارهای این پیاده سازی در بخش ارائه خواهد شد. 5. شبکه تست Hyperledger Fabric v2.4.3 استفاده شد. شبکه آزمایشی بر اساس آموزش های ارائه شده توسط Hyperledger Fabric2 در Docker مستقر شد. قرارداد هوشمند سپس به کار گرفته شد (به تفصیل در بخش 4). ذخیره سازی فایل های رمزگذاری شده توسط IPFS، که یک پایگاه داده توزیع شده تورنت است، مدیریت می شود که از هش فایل ها برای آدرس دهی محتوای خود استفاده می کند. گره IPFS نیز در Docker مستقر شد. برای استقرار IPFS دو دایرکتوری (مرحله‌بندی و داده) وجود داشت. استفاده از دستور مستلزم پیمایش به دایرکتوری ریشه شبکه آزمایشی است که توسط Hyperledger Fabric [8] ارائه شده است. رمزگذاری خود مبتنی بر شناسه از طریق قرارداد هوشمند Hyperledger Fabric Based 7 که بر روی سیستم فایل میزبان نصب شده است تا داده‌های ذخیره‌شده را در زمانی که ظرف متوقف می‌شود، حفظ کند. Hyperledger Fabric کیت رسمی توسعه نرم افزار (SDK) را برای 3 زبان ارائه می دهد: Go، Java، Javascript. Go به دلیل سهولت ادغام با Hyperledger Fabric و IPFS برای اجرای پروژه انتخاب شد. کتابخانه رمزگذاری در Rust نوشته شده است و در WebAssembly کامپایل شده است، از این رو راهی برای فراخوانی WebAssembly مورد نیاز بود. Go همچنین از کتابخانه Wasmer پشتیبانی می کند که امکان فراخوانی عملکرد WebAssembly را مستقیماً از کد Go فراهم می کند. 4 خود رمزگذاری مبتنی بر ID 4.1 ادغام هویت در رمزگذاری این مقاله توسعه ای برای الگوریتم پیشنهاد شده توسط ایروین [9] ارائه می دهد. مرحله رمزگذاری در الگوریتم اصلی اصلاح شده است تا هویت شخصی را که الگوریتم را در فرآیند رمزگذاری اجرا می کند، شامل شود. به جای استفاده از بخشی از هش قطعه به عنوان یک کلید برای AES 128، از نتیجه XoR از هویت هش شده و هش تکه به عنوان کلید استفاده می شود. هویت می تواند هر رشته ای با هر طولی باشد. اگر طول این رشته کوتاهتر از طول کلید باشد، تابع چرخه به رشته اعمال می شود که تکرار کننده یک رشته را تکرار می کند. تابع هش SipHash 1-3 برای هش کردن هویت یک کاربر، قبل از ارسال آن به تابع XoR استفاده می شود. شکل 2 روند رمزگذاری یک فایل را با استفاده از نسخه اصلاح شده خود رمزگذاری با هویت ادغام شده در فرآیند رمزگذاری نشان می دهد. شکل 2. فرآیند رمزگذاری خود مبتنی بر شناسه 8 I. Grishkov et al. رمزگشایی فایل، که با استفاده از رمزگذاری مبتنی بر ID رمزگذاری شده است، مشابه رمزگشایی خود رمزگذاری معمولی است و کلید AES 128 تنها بخش متفاوت آن است. رمزگشایی کلید را به همان روشی که رمزگذاری با اعمال تابع XoR به هش هویت و هش تکه از نقشه داده ها انجام می دهد، محاسبه می کند. اجرای طرح رمزگذاری را می توان در GitHub3 یافت. 4.2 اتصال الگوریتم رمزگذاری و برنامه محلی اجرای خود رمزگذاری مبتنی بر هویت صرفاً در Rust نوشته شده است، در حالی که برنامه مشتری در Go نوشته شده است. این تقاضا برای راهی برای ادغام کتابخانه Rust در کد Go ایجاد می کند. از جمله راه حل های مقابله با این مشکل عبارتند از: 1. از ابزار Go برای جمع آوری کد Go و کامپایل کد Rust در یک کتابخانه ثابت استفاده کنید. سپس کد کامپایل شده را با استفاده از اسمبلی اضافی " چسب - کد " [17] پیوند دهید. 2. Rust را به یک کتابخانه ثابت کامپایل کنید و آن را از کد Go با استفاده از شبه کتابخانه C داخلی Go برای تعامل با رابط های بومی فراخوانی کنید. 3. کد Rust to WebAssembly (WASM) را کامپایل کنید و با استفاده از Wasmer library4 آن را از Go فراخوانی کنید. همه روش ها با موفقیت امتحان شده اند. دو روش اول اجازه کامپایل متقابل را نمی دهند، زیرا هر دوی آنها نیازمند کامپایل Rust در کتابخانه ایستا هستند که مخصوص پلتفرم است. علاوه بر این، روش اول نیاز به استفاده از زبان اسمبلی دارد که در معماری‌های پردازنده و سیستم‌عامل‌های مختلف متفاوت است. روش دوم همچنین از شبه کتابخانه C استفاده می کند که اجازه کامپایل متقابل کد Go را نمی دهد. به طور کلی، هر دو روش بسیار خاص پلتفرم هستند، که باعث می شود انتخاب کمتری داشته باشند. روش سوم برای اتصال کتابخانه Rust به کد Go انتخاب شد. کامپایل Rust در WASM برای استفاده به عنوان یک برنامه مستقل یا یک کتابخانه، می تواند با استفاده از دستور زیر انجام شود: $ c a r g o b u i l d −−t a r g e t =[ c h o s e n t a r g e t ] که در آن هدف انتخابی یک هدف WebAssembly است که می تواند wasm32- ناشناخته-unknown باشد. wasm32-wasi. دومی مورد استفاده قرار گرفت، زیرا با استفاده از WASI API5 که یک API سیستمی است که دسترسی به چندین عملکرد سیستم عامل مانند دسترسی به سیستم فایل را فراهم می کند، کامپایل می شود. سپس فایل WASM به دست آمده در یک پوشه مخفی در فهرست اصلی کاربر قرار می گیرد تا بعداً با کد Go بارگیری شود. از آنجایی که کد WASM در یک ماشین مجازی (VM) استفاده می شود، از سیستم عاملی که روی آن اجرا می شود مستقل است، بنابراین فقط برای یک هدف نیاز به کامپایل دارد. 3 https://github.com/ilyagrishkov/ib-self-encryption-rust. 4 https://wasmer.io/. 5 https://wasi.dev/. رمزگذاری خود مبتنی بر شناسه از طریق قرارداد هوشمند مبتنی بر پارچه Hyperledger 13 در Go است، زمان اجرا زمانی که توابع Rust از Go فراخوانی می شوند در مقایسه با زمان اجرای Rust خالص می تواند متفاوت باشد. فایل هایی با اندازه های 100-، 250-، 500-، 750 کیلوبایت، 1 مگابایت، 10-، 25-، 50-، 75- و 100 مگابایت برای محک زدن پیاده سازی Rust خالص و همچنین WASM + ایجاد شده اند. برو پیاده سازی ها علاوه بر این، برای این معیار، هم کد Rust و هم کتابخانه WASM با استفاده از حداکثر سطح بهینه‌سازی ارائه شده توسط کامپایلر Rust بهینه شدند. شکل 5. وابستگی زمان اجرای الگوریتم خود رمزگذاری مبتنی بر شناسه در Rust خالص از اندازه فایل معیار اولیه تنها بر روی تابع رمزگذاری انجام شد و زمان اجرای اجرای Rust خالص را اندازه‌گیری کرد. شکل 4 نتایج محک زدن را نشان می دهد. نمودار وابستگی تقریباً خطی بین اندازه فایل و زمان رمزگذاری آن را نشان می دهد. این وابستگی را می توان با این واقعیت توضیح داد که سخت ترین محاسبات فرآیند رمزگذاری AES 128 است و با افزایش اندازه فایل، تعداد تکه های آن به افزایش می یابد. هر تکه از فایل اصلی باید به صورت جداگانه رمزگذاری شود، از این رو زمان محاسبه به صورت خطی با اندازه فایل افزایش می یابد. با افزایش خطی زمان اجرای تابع رمزگذاری به دلیل نیاز محاسباتی AES 128 و الگوریتم های هش، فرآیند رمزگشایی یکسان خواهد بود، زیرا از الگوریتم های مشابهی برای رمزگشایی استفاده می کند. برای دستیابی به نتایج معیار عینی تر، فایل در هر اندازه 100 بار رمزگذاری شده و میانگین محاسبه شده است. به منظور تجسم زمان اجرا، نموداری در پایتون با استفاده از MatPlotLib8 ایجاد شد. نمودار شامل یک هیستوگرام 25 bin است که هر کدام نشان دهنده چگالی یک اندازه گیری خاص است. دنبال کنید