Continuing down the path of securing system privacy via Intel SGX, Ryoan explores a system to facilitate secret data sharing in a distributed scenario with mutually distrusting entities. Today, there has been and continues to be a proliferation of 3rd party data processing services and data manipulation platforms. The myriad of data analysis companies, from web analytics like Google Analytics to machine learning platforms through AWS, provide their services not so much through local applications, but more as SaaS services. This requires users who may want to keep their data secret to service providers that they do not necessarily trust. The goal of Ryoan is to employ SGXs, like Haven, to allow users to use a service without having to trust the application or platform and have reassurance that their data is kept secret.

Ryoan’s usage is framed as a requested oriented data model, where data is uploaded, processed one time, and returned to the user. No state is persisted by the service provider. From a TCB (Trusted Computing Base) and threat model standpoint, users and service providers are assumed to distrust one another, but all parties trust Ryoan and SGX. The main innovation of this paper is, to prevent modules, the service itself, from reading secrets out of memory, the module is executed inside an enclave. By sandboxing a module’s accessible memory + system calls, enforcing encryption, and having Ryoan control a module’s lifecycle (initialize ⇒ read input ⇒ process ⇒ write output), a module is unable to write out user data, collude with malicious users, or persist state between requests.

While the threat model is well defined by the authors, I felt that it doesn’t capture certain potential issues. Buggy code that is vulnerable to leaking its own secrets will expose information during execution. While it doesn't compromise privacy, denial of service attacks are also possible. Applications that use repeated computations on similar input data would not be masked by hashing since the output would be deterministic. In addition, applications requiring storage or a lot of memory would not be able to persist due to Ryoan’s primitive that state should not be stored across requests; therefore, any information exceeding Ryoan's storage capacity would logically not be processed. Multi-user computation is not possible due to the designs to prevent module-user collusion. The model also includes hardware in the TCB, leaving it open to hardware security issues such as page faults or timing attacks.

The most immediate extensions would be to address some of the aforementioned limitations. Ryoan enforces a lot of properties on a module for a variety of reasons ranging across security, performance, and compatibility. When put into practical use, I think it’d be interesting to see whether the whole suite of applications is absolutely necessary. For instance, NaCl ensures only module memory can be addressed, syscalls are not made directly to hardware, and SGX state cannot be modified. It’d be interesting to see whether, given a different TCB, such as running both the module and OS in an enclave, would render some of Ryoan’s properties unnecessary while enjoying a performance gain. The multiuser collaboration issues seem to be addressed in the ML context with federated learning, which will be interesting to draw comparisons with.