No content

The Way to Public Network How should confidential information be handled on public networks? The nature of blockchain ü Data backup ü Hardware failures ü Encryption of communications Several issues to be addressed p Physical security measures p Unauthorized access p Access log 

The Way to Public Network How should confidential information be handled on public networks? ☠ ☠ ？ ？ ☠ ☠ KMS Private Network Public and Consortium Network 

Security Incidents and Compliance What are the trends in security damage? Org. Domain Damage Vulnerability 2022-02 W. Wormhole Bridge 324M USD Message forgery 2022-03 A.I. Axie Infinity Game 625M USD Intrusion into validator 2022-06 H. Harmony Bridge 100M USD Undisclosed 2022-08 S Solana Cryptocurrency 8M USD Wallet key leakage 2022-08 N. Nomad Bridge 190M USD Message forgery 2022-09 W. Wintermute Market 160M USD Address vulnerability 2022-10 B. Binance Exchange 570M USD Message forgery 2022-11 F? FTX Exchange 480M USD Illegal fund outflow? Theft of ｃrypto assets on blockchain 

HSM (USB) HSM (Server) Firewall • Side-channel attack resistance • Tamper resistant • High speed • Side-channel attack resistance • Tamper resistance • Good cost performance Server OS/HW HSM (USB device) ？ ？ Server OS/HW HSM (server) ？ ？ Local Storage Secure Key Management How do we secure confidential information? Server TEE • Side-channel attack resistance • Tamper resistant • High speed • Good cost performance • Programmable • No hardware cost ☠ OS/HW Server OS/HW TEE ？ ？ 

HSM (USB) Local Storage Secure Key Management How do we secure confidential information? Server HSM (Server) TEE Firewall • Side-channel attack resistance • Tamper resistant • High speed • Good cost performance • Programmable • Side-channel attack resistance • Tamper resistant • High speed • Side-channel attack resistance • Tamper resistance • Good cost performance • No hardware cost ☠ Server OS/HW OS/HW HSM (USB device) ？ ？ Server OS/HW HSM (server) ？ ？ Server OS/HW TEE ？ ？ 

HSM (USB) HSM (Server) Firewall • Side-channel attack resistance • Tamper resistant • High speed • Side-channel attack resistance • Tamper resistance • Good cost performance Server OS/HW HSM (USB device) ？ ？ Server OS/HW HSM (server) ？ ？ Local Storage Secure Key Management How do we secure confidential information? Server TEE • Side-channel attack resistance • Tamper resistant • High speed • Good cost performance • Programmable • No hardware cost ☠ OS/HW Server OS/HW TEE ？ ？ 

Our Requirements What does LINE Blockchain require? Intel® Software Guard Extensions Technology Intel® SGX 1. Programmable 2. High Security 3. Low Latency (Throughput is not particularly important) 4. Low Cost ! 

Ordinary Memory (Untrusted) Enclave (Trusted) Features Intel® SGX Hardware-supported memory encryption technology ⎯ General computer memory is not encrypted, and applications run in insecure space. ⎯ Intel SGX technology prepares an encrypted, secure space on its memory called Enclave. • Encryption is based on hardware support. • Can execute encrypted instructions. • Typically, 128MB allocated, 92MB available. Computer 

Ordinary Memory (Untrusted) Enclave (Trusted) Application Features Intel® SGX Hardware-supported memory encryption technology ⎯ The application as a whole is divided into at least two parts: • Executable file with main() entry point. • Shared library running in the Enclave. ⎯ Functions in trusted and untrusted spaces can call each other. • Transparently mediated by the SGX architecture. main() shared library Computer 

Ordinary Memory (Untrusted) Enclave (Trusted) Application Features Intel® SGX Hardware-supported memory encryption technology ⎯ Processing in Enclave cannot do so much. • Basic control instructions and CPU operations. • ANSI-C functions that don’t rely on system calls, such as memory operations. • Cryptographic functions provided by SGX. ⎯ Processing that cannot be done in Enclave should be done in an untrusted area. • General system call, e.g., file, console, and socket I/O, threading, signaling, etc. • A bit like kernel or eBPF programming. main() shared library Computer 

Intel® SGX Development How does the application work? int main(…){ foo(…); } void bar(…){ … } void foo(…){ bar(…); } Enclave CPU Storage Console Memory int main(…){ foo(…); } void bar(…){ … } void foo(…){ bar(…); } Application Source Library Source enclave{ trusted{ public int foo(…); }; untrusted{ void bar(…); }; }; EDL … Configuration RSA Private Key (HSM) Development Build Runtime MyApplication (executable file) MyApplication.signed.so (shared library) Edger8r gcc g++ MyApplication.so signer Enclave_t.c Enclave_t.h Enclave_u.c Enclave_u.h gcc g++ 

Intel® SGX Development How does the application work? int main(…){ foo(…); } void bar(…){ … } void foo(…){ bar(…); } Enclave CPU Storage Console Memory int main(…){ foo(…); } void bar(…){ … } void foo(…){ bar(…); } Application Source Library Source Development Build Runtime MyApplication (executable file) MyApplication.signed.so (shared library) 

Intel® SGX Development How does the application work? int main(…){ foo(…); } void bar(…){ … } void foo(…){ bar(…); } Enclave CPU Storage Console Memory int main(…){ foo(…); } void bar(…){ … } void foo(…){ bar(…); } Application Source Library Source enclave{ trusted{ public int foo(…); }; untrusted{ void bar(…); }; }; EDL Development Build Runtime MyApplication (executable file) MyApplication.signed.so (shared library) Edger8r gcc g++ MyApplication.so Enclave_t.c Enclave_t.h Enclave_u.c Enclave_u.h gcc g++ 

Intel® SGX Development How does the application work? int main(…){ foo(…); } void bar(…){ … } void foo(…){ bar(…); } Enclave CPU Storage Console Memory int main(…){ foo(…); } void bar(…){ … } void foo(…){ bar(…); } Application Source Library Source enclave{ trusted{ public int foo(…); }; untrusted{ void bar(…); }; }; EDL … Configuration RSA Private Key (HSM) Development Build Runtime MyApplication (executable file) MyApplication.signed.so (shared library) Edger8r gcc g++ MyApplication.so signer Enclave_t.c Enclave_t.h Enclave_u.c Enclave_u.h gcc g++ 

Designing Our KMS with SGX How do we handle confidential information? Setup 1. Generate a new key-pair in Enclave. Or import it from an external source if the setup environment is trusted. 2. Seal (encrypt) the private key with the SGX function and return it. 3. Store the sealed private key and plain public key in Application. Ostracon (Blockchain Node) KMS Firewall Enclave Application 2. Seal 1. Generate 3. Store 

Designing Our KMS with SGX How do we handle confidential information? Ostracon (Blockchain Node) KMS Firewall Enclave Application 2. Connect ？ Start 1. Load the sealed key and place it in memory on Application side. 2. Connect from KMS to get through the firewall. • Authenticate each other. • Check node ID. 1. Load 

Designing Our KMS with SGX How do we handle confidential information? Ostracon (Blockchain Node) KMS Firewall Enclave Application Input Output 3. Unseal 4. Calculate 2. Pass 1. accept 5. return Cryptographic Calculation 1. Accepts sign request from blockchain node. 2. Pass the sealed key and input data to Enclave. 3. Unseal (decrypt) the key within Enclave. 4. Create signature and return it to Application. 5. Returns the signature to blockchain node. 

Designing Our KMS with SGX How do we handle confidential information? Backup Using Remote Attestation is the way to go. • Both nodes can verify that it’s not a counterfeit. • Considering online backup in a reliable manner, perhaps the same design would be used. Node A Enclave Enclave Node B Intel® Attestation Service Enclave Application 2. Seal 1. Import 3. Store Or, if trusted setup can be assumed, • Key management is done externally. • Can use a common key into multiple KMSs. • Key export should not be implemented. ？ Trusted environment 

Designing Our KMS with SGX How do we handle confidential information? Backup Using Remote Attestation is the way to go. • Both nodes can verify that it’s not a counterfeit. • Considering online backup in a reliable manner, perhaps the same design would be used. Node A Enclave Enclave Node B Intel® Attestation Service Enclave Application 2. Seal 1. Import 3. Store Or, if trusted setup can be assumed, • Key management is done externally. • Can use a common key into multiple KMSs. • Key export should not be implemented. ？ Trusted environment 

Modularized Backend • SGX backend is for secure production. • Mock backend is for testing but fully functional. • It’s useful for testing and CI environment. • Compatible with a variety of security technologies. • HSM that meet our requirements • Other TEE technology, such as AMD, ARM, RISC-V, etc. • Incompatible future SGX version KMS Application RPC HSM Backend Enclave HSM Designing Our KMS with SGX How do we handle confidential information? Mock Backend etc. SGX Backend 

KMS Ostracon (Blockchain Node) MacBook Pro 2019 (Core-i7 2.8GHz 4C/8T) DELL Optiplex 7070 SFF (Core-i5 9500 4.4GHz 6C/6T) Enclave Cost and Performance How had it worked with SGX? [μs] API Local Remote KMS Behind RPC Ping (not implemented) 420.601 12.717 Sign 0.718 619.484 213.166 VRFProve 150.236 1,750.194 1,140.593 ProtocolBuffers Secure Protocol TCP/IP USB Type-C 1Gbps Hub NIC TCP/IP Secure Protocol ProtocolBuffers Edger Routine Round Trip 1 㲒 400μs Round Trip 2 㲒 13μs SignerClient RPC Behind RPC ü Programmable • We could implement our signature algorithm and run it in Enclave. ü High Security • The private key is never exposed to the untrusted domain in plaintext. • The code of our signature algorithm cannot be tampered with. ü Low Latency • 0.6ms for sign, 1.8ms for slow VRF prove. • Almost no impact on block node. ü Low Cost • Typical desktop PC and server cost only. Sign() VRFProve() Ping() Sign() VRFProve() Remote KMS Local 

KMS Ostracon (Blockchain Node) MacBook Pro 2019 (Core-i7 2.8GHz 4C/8T) DELL Optiplex 7070 SFF (Core-i5 9500 4.4GHz 6C/6T) Enclave Cost and Performance How had it worked with SGX? [μs] API Local Remote KMS Behind RPC Ping (not implemented) 420.601 12.717 Sign 0.718 619.484 213.166 VRFProve 150.236 1,750.194 1,140.593 ProtocolBuffers Secure Protocol TCP/IP USB Type-C 1Gbps Hub NIC TCP/IP Secure Protocol ProtocolBuffers Edger Routine Round Trip 1 㲒 400μs Round Trip 2 㲒 13μs SignerClient RPC Behind RPC ü Programmable • We could implement our signature algorithm and run it in Enclave. ü High Security • The private key is never exposed to the untrusted domain in plaintext. • The code of our signature algorithm cannot be tampered with. ü Low Latency • 0.6ms for sign, 1.8ms for slow VRF prove. • Almost no impact on block node. ü Low Cost • Typical desktop PC and server cost only. Sign() VRFProve() Ping() Sign() VRFProve() Remote KMS Local 

Impression of Development What hardships have I encountered? Environment setup ☁ SGX-compatible hardware ☁ BIOS, kernel, and driver combinations Development ☁ Need to modify a few libraries ☁ ｓｔｄｃ has been replaced ☀ Integration with Rust in FFI ☁ Makefile tend to get complexed Runtime ☀ Works well ! 

Impression of Development What hardships have I encountered? Environment setup ☁ SGX-compatible hardware ☁ BIOS, kernel, and driver combinations Development ☁ Need to modify a few libraries ☁ ｓｔｄｃ has been replaced ☀ Integration with Rust in FFI ☁ Makefile tend to get complexed Runtime ☀ Works well ! 

Gen 3 Gen 2 LINE Blockchain Where will it be used? Bamboo (2019) LINK (cryptocurrency) Cashew, Daphne (2020) LINE Blockchain Developers LINE NFT LINE BITMAX/DOSI Wallet Ebony, Finschia (202x) LINE Blockchain Developers LINE NFT LINE BITMAX/DOSI Wallet 3rd party dApps Alder (2018) LINK Point End of Service Getting Ready Gen 1 

TAKAMI Torao Blockchain Engineering Team LINE Corp. 

Thank You