text:
\section{Introduction}

First introduced in 2015, Intel's Software Guard Extensions (SGX) technology
inspired diverse applications but also increasingly sophisticated attacks:
researchers successfully adapted speculative execution
attacks~\cite{VanBulck2018a}, injected software faults~\cite{Murdock2020a}, and
exploited side channels introduced by shared caches~\cite{Brasser2017a}, all
with the goal of exfiltrating information that was meant to remain in the
enclave.  The underlying flaw that most attacks take advantage of is that the
untrustworthy operating system and the enclave share a CPU, which provides many
options for side channel attacks.

In 2020, several cloud providers began offering ``confidential computing''
solutions; Google's is based on AMD's Secure Encrypted Virtualization
(SEV)~\cite{googlecc} while Microsoft's is based on SGX~\cite{azurecc}.  Both
offerings inherit the attack classes that plague their respective architectures.
Amazon took a different path by offering a new enclave architecture
based on their Nitro virtual machine isolation technology~\cite{nitro-enclaves}.
Nitro enclaves are separate virtual machines with hardware-enforced CPU,
memory, and device isolation, which imposes limits on access by untrustworthy code.
While the architecture appears promising, Nitro enclaves
remain difficult to use: documentation is sparse, few applications exist, and
enclaves can only interact with the parent EC2 instance via a constrained,
socket-like interface.  This paper presents the design, implementation, and
real-world application of a software framework that facilitates the development
of networked Nitro enclaves.  Key features of our framework include
(\emph{i}) the ability for enclave code to seamlessly and safely access the
Internet;
(\emph{ii}) a design for the horizontal scaling of enclaves by synchronizing
secret key material; and
(\emph{iii}) a reproducible build system and tooling that allows users to
remotely verify an enclave's authenticity.

During the development of our framework, we had to overcome several challenges.
First, Nitro enclaves are meant to be highly constrained environments and
therefore lack a dedicated networking interface.  We designed a mechanism that
allows enclaves to seamlessly send and receive data over the Internet while
maintaining an allow list of destinations, for defense in depth in case of
enclave compromise.
Second, the attestation process for Nitro enclaves was not designed to be
performed over the Internet.  We developed a way to bind a TLS session to
an attestation document to assure clients that they are communicating with
an authentic enclave.
Third, we had to devise a reproducible and yet easy-to-use build pipeline that
allows end users---regardless of their operating system---to compile the enclave
application and end up with the exact same image ID as the enclave provider.
Fourth, there is no out-of-the-box way for enclaves to scale horizontally while
synchronizing their key material.  We therefore designed a mechanism that allows
enclaves to securely share their key material.

Having overcome the above design challenges, we implemented an easy-to-use Go
framework that abstracts away the difficulties and pitfalls of working with
networked enclaves.  The use of Go allows for rapid prototyping and greatly
reduces the risk of memory corruption bugs because of Go's memory safety.  We
conduct latency measurements to show that our framework can handle
high-throughput and real-time applications, and we demonstrate its usefulness
and robustness by building two applications on top of it.

\paragraph{Contributions}

This work makes three core contributions.

\begin{itemize}
  \item The design and implementation of a freely available Go framework that
    facilitates the implementation and deployment of enclave applications.  The
    framework consists of a library that an application can use to run as an
    enclave, and tooling that facilitates deterministic builds and seamless
    communication with the secure enclave.

  \item We make it possible via our framework to turn enclaves into networked
    applications that can easily scale horizontally to respond to increases in
    load.

  \item We build two real-world applications on top of our framework, the first
    of which---a remotely verifiable IP address pseudonymization system---is a
    contribution in its own right.
\end{itemize}

\paragraph{Structure}

Section~\ref{sec:background} provides background on secure enclaves in general
and AWS Nitro enclaves in particular.  Section~\ref{sec:design} introduces the
design and implementation of our software framework in addition to the build
process that guarantees reproducible enclave application builds, followed by
Section~\ref{sec:applications}, which presents two production-quality
applications that we built on top of our framework.  We evaluate our framework
in Section~\ref{sec:evaluation} and discuss its limitations in
Section~\ref{sec:limitations}.  Finally, Section~\ref{sec:related-work}
contrasts our work with past research.

\section{Applications}
\label{sec:applications}

We demonstrate the practicality of our framework by building two applications on
top of it.  First, in a novel system that pseudonymizes client IP addresses for
anti-fraud (\S~\ref{sec:pseudonymization}); second, to implement the shuffler
component that is part of Bittau et al.'s PROCHLO paper~\cite{Bittau2017a}
(\S~\ref{sec:shuffler}).  In both cases, we had to overcome minor obstacles but
found that our framework greatly facilitated the deployment of enclave code.

While our framework is written in Go, developers can build enclave applications
in languages other than Go, by taking advantage of a foreign function interface
(FFI) that allows Go code to invoke functions in other languages.  We
successfully moved a Rust code base into a Nitro enclave by implementing a
lightweight, Go-based wrapper (in less than 200 lines of code, excluding our
framework's code) that interacts with the Rust code via an FFI.\footnote{The
code is available at: \url{https://github.com/brave-experiments/star-randsrv}.}
Importantly, the compilation process is still reproducible as long
as the Rust code's dependencies are pinned via Rust's Cargo tool chain.

\subsection{IP Address Pseudonymizer}
\label{sec:pseudonymization}

Our first application is the system that originally motivated us to build the
enclave framework. Consider a service provider that offers various services to
its users.  The service provider seeks to know as little as possible about its
users, which means that it doesn't capture and store any of its users' IP
addresses.  IP addresses are however an important signal in the service
provider's fight against a subset of its users that commit fraud.  This
constitutes a conundrum: Should the service provider collect all its users' IP
addresses to strengthen its anti-fraud efforts?  Or continue to discard the
addresses, and tolerate the fraud?

This section presents an application that strikes a balance between these two
extremes; an IP address pseudonymization system that can verifiably pseudonymize
IP addresses.  The service provider can then run its anti-fraud logic over
pseudonymized IP addresses rather than real ones.  While some information is
lost in the process, we argue that what's most important---the relationship
between IP addresses---can be preserved thanks to our use of the Crypto-PAn
scheme that Xu et al. presented in their 2001 paper~\cite{Xu01a}.  Crypto-PAn
encrypts both IPv4 and IPv6 addresses by implementing a 1:1 mapping $f$ that is
keyed by $k$ from an IP address to its pseudonymized equivalent while
\emph{preserving the address's prefix}, i.e., two IP addresses that share an
$n$-bit prefix also share an $n$-bit prefix after pseudonymization as
illustrated by the following example:

\begin{align}
f(k, \textrm{``\underline{10.0.0.}1''})\phantom{23} = \textrm{``\underline{242.32.192.}193''} \\
f(k, \textrm{``\underline{10.0.0.}123''}) = \textrm{``\underline{242.32.192.}154''}
\end{align}

Figure~\ref{fig:address-anonymizer} illustrates the system design.  Clients
periodically communicate with a service behind a reverse TLS proxy whose
job---among other things---is to hide client IP addresses from the service.  The
proxy is configured to mirror incoming client requests to the enclave, but with
client IP addresses intact, in the form of a custom HTTP header like
\texttt{X-Client-Addr: 1.2.3.4}.  The service is interactive, and responds to
the client, but the enclave is passive, and simply consumes the requests.
Recall that the (untrusted) EC2 host that hosts the enclave is unable to see
the client's IP address because the TLS proxy establishes a TLS session that's
terminated \emph{inside} the enclave.  The pseudonymizer takes as input client
requests, extracts the IP address that the proxy inserted from the HTTP header,
pseudonymizes them, and forwards pseudonymized addresses in batches to the
configured back end.  Components in dark gray are under the service provider's
control.

\begin{figure}[t]
\centering
\input{sections/figures/pseudonymizer-design}
\caption{Clients communicate with a service that's available behind a
  third-party TCP proxy whose purpose is (among other things) to drop client IP
  addresses, so the service never sees them.  The proxy is configured to mirror
  incoming client requests \emph{with} IP address to the enclave, where
  addresses are pseudonymized and finally forwarded to a back end for analysis.}
\label{fig:address-anonymizer}
\end{figure}

One problem however remains: how do clients know that the TLS proxy is in fact
configured to discard client IP addresses before forwarding requests to the
service?  Unfortunately, cloud providers don't offer satisfying solutions for
this problem but some cloud providers allow for the creation of roles whose
permissions are configurable.  The service provider can create a read-only role
in the TLS proxy's configuration interface and publish the credentials for this
role.  Doubtful users can then log in to this role and verify that the TLS proxy
is configured to discard IP addresses when forwarding requests to the service.
As long as the TLS proxy operator is a neutral third party with no incentive to
lie, which is typically the case, both the client and service provider can trust
it.  We acknowledge that this is not an elegant solution but a mere hack, to
work around the shortcoming of Nitro enclaves not having a networking interface.
If enclaves had a networking interface that could not be monitored by the
untrusted EC2 host, clients could directly talk to the enclave, obviating the
need for a TLS proxy that hides client IP addresses from the EC2 host.

\paragraph{Side channels}
The untrusted EC2 host never sees client IP address in plaintext
but it can exploit timing and volume side channels to infer information about
the encrypted requests that the TLS proxy forwards to the enclave.  We close
this side channel by adding code to the enclave application which queues
pseudonymized IP addresses until two conditions are true: (\emph{i}) we have at
least $n$ pseudonymized addresses, and (\emph{ii}) at least $t$ minutes have
passed.

\paragraph{Key rotation} A single pseudonymous IP address without context cannot
be reversed and reveals nothing about its corresponding plaintext IP address but
that changes if the service provider expects the client to repeatedly report its
IP address to the enclave.  For example, a sequence of pseudonymized IP
addresses can reveal either that (\emph{i}) the client has not changed its IP
address, or (\emph{ii}) the client changed its IP address but is likely to use
the same ISP (e.g., if the /24 prefix remains the same), or (\emph{iii}) the
client changed IP addresses \emph{and} ISPs (e.g., if the prefixes of the
pseudonymous IP addresses share less than, say, eight bits).  While this is
useful information for anti-fraud operations,\footnote{For example, a service
provider would deem a client that constantly changed ISPs suspicious; it is
likely to use proxies to connect to the service provider's infrastructure.} it
also reveals information about a given client's location, and service providers
may want to err on the side of privacy instead.  We therefore added a mechanism
for periodic key rotation, so a given client's pseudonymized IP addresses are
only meaningful within a given rotation period.  According to the results of
Padmanabhan et al., we believe that a key rotation period of three weeks strikes
a useful balance between privacy for the client and usefulness for the service
provider~\cite[\S~3.2]{Padmanabhan20a}: several ISPs re-assign many of their
users' IP addresses in less than---or up to---two weeks.

In the final step, the enclave submits the client's pseudonymized IP address and
a hash of the key to the service provider's back end, where anti-fraud logic is
implemented.  The implementation details of both the back end and its anti-fraud
logic are beyond the scope of this paper.

\paragraph{Implementation}
Our pseudonymization service counts approximately 1,000 lines of code, including
comments and tests.  It is important to keep the source code small for both
security and transparency: a large code base is more likely to have
security-critical bugs and is also more difficult for users to audit.

\paragraph{Alternative pseudonymization}
In addition to Crypto-PAn, we implemented a second pseudonymization method that
is based on HMAC-SHA-256.  Like Crypto-PAn, the HMAC is keyed by a 160-bit
secret that the enclave generates when first bootstrapping.  Unlike Crypto-PAn
however, the HMAC-based method does not preserve the prefixes of IP addresses:
two IP addresses that differ in only a single bit will result in entirely
different hashes.  On the privacy/utility spectrum, the HMAC-based method
therefore leans more toward privacy.

\subsection{$k$-anonymity Enforcer}
\label{sec:shuffler}

Bittau et al.'s SOSP'17 paper~\cite{Bittau2017a} proposes a private analytics
system that helps service providers gain insight into their clients' usage
patterns.  Their system---called PROCHLO---consists of three components:
(\emph{i}) software running on the client, which can (but doesn't have to) add
local differential privacy to client measurements.  Measurements consist of
product-relevant answers to questions like ``has the user interacted with her
browser in the last 24 hours?'' These measurements are then sent to (\emph{ii})
a shuffler, which enforces a configurable $k$-anonymity threshold on incoming
measurements.  The shuffler then sends measurements meeting that threshold to
(\emph{iii}) an analytics system that the service provider uses to explore
users' anonymized data.  The PROCHLO paper envisions the shuffler running in a
secure enclave; otherwise users would have no reason to trust that the shuffler
is in fact enforcing $k$-anonymity thresholds.  To that end, the authors
designed the shuffler to run inside an Intel SGX enclave, which was challenging
considering the memory constraints that SGX imposes.  For more details about the
shuffler, refer to the original PROCHLO paper~\cite[\S~3.3]{Bittau2017a}.

As part of an unrelated research project, we were experimenting with private
telemetry, and we therefore used our framework to re-implement the shuffler in
approximately 1,000 lines of code.\footnote{The code is available at:
\url{https://github.com/brave-experiments/p3a-shuffler}.} Our implementation is
a near-complete clone of the shuffler as it was proposed in the PROCHLO paper
but for simplicity, we did not implement nested
encryption~\cite[\S~3]{Bittau2017a}.  Figure~\ref{fig:shuffler} shows that our
shuffler takes as input confidential client measurements and enforces a
configurable $k$-anonymity threshold on those measurements.  Every $t$ seconds,
the shuffler discards messages that don't meet the threshold and forwards the
remaining messages to its back end.\footnote{The variable $t$ depends on the
rate of incoming measurements.  Reasonable values can range from hours (if the
shuffler constantly sees a high rate of incoming measurements) to days.} Before
clients agree to sending their sensitive measurements to the shuffler, they
audit its source code and perform remote attestation, to convince themselves
that their measurements are processed by an authentic enclave.

\begin{figure}[t]
\centering
\input{sections/figures/shuffler-design}
\caption{A conceptual overview of our shuffler implementation.  Clients send
  measurements to the shuffler, which enforces a $k$-anonymity threshold---in
  this case for $k$=2. Only one of the two measurement types passes the
  threshold and is forwarded to the back end.}
\label{fig:shuffler}
\end{figure}

Compared to Bittau et al.'s original, SGX-based design, our Nitro-based
implementation has two key advantages: (\emph{i})~Nitro's underlying hardware
isolation makes our implementation more robust to hardware side channel attacks
and (\emph{ii})~Nitro doesn't suffer from the same resource constraints as SGX,
which renders our implementation easier to use and less error-prone.

\paragraph{Side channels}
The untrustworthy parent EC2 host can take advantage of the same side
channel as with the IP address pseudonymizer.  In particular, the EC2 host
can observe when and how many requests clients make.  Like with the IP address
pseudonymizer, the PROCHLO paper closes this side channel by aggregating
requests, preventing the EC2 host from linking incoming to outgoing
requests.

\section*{Resources}

The following list has URLs to all code repositories that are mentioned
throughout work.

\begin{itemize}
  \item Enclave framework:\\
    {\small \url{https://github.com/brave-experiments/nitriding}}

  \item Remote attestation tool set:\\
    {\small \url{https://github.com/brave-experiments/verify-enclave}}

  \item TCP proxy:\\
    {\small \url{https://github.com/brave-experiments/viproxy}}

  \item SOCKS proxy:\\
    {\small \url{https://github.com/brave-intl/bat-go/tree/nitro-utils/nitro-shim/tools/socksproxy}}

  \item IP address pseudonymization system:\\
    {\small \url{https://github.com/brave-experiments/ia2}}

  \item PROCHLO shuffler:\\
    {\small \url{https://github.com/brave-experiments/p3a-shuffler}}

  \item Go application using Rust FFI:\\
    {\small \url{https://github.com/brave-experiments/star-randsrv}}

\end{itemize}

\section{Evaluation}
\label{sec:evaluation}

We evaluate our enclave framework with respect to
security (\S~\ref{sec:security}),
financial cost (\S~\ref{sec:cost}), and performance.  As for performance, we
study the rate at which one can generate
attestation documents (\S~\ref{sec:attestation-performance}) and
measure end-to-end request latency and throughput (\S~\ref{sec:end-to-end}).

\subsection{Security Considerations}
\label{sec:security}

There are three key components to the overall security of enclave applications;
(\emph{i}) Amazon's Nitro enclave system itself, (\emph{ii}) our framework, and
(\emph{iii}) the application that runs on top of our framework.

The very foundation of our framework's security lies in the soundness of the
design of Nitro enclaves.  While Amazon published the conceptual design, the
concrete hardware and software implementation remains confidential.  The
decision to allocate physically separate resources to enclaves appears promising
but only time will tell if Nitro enclaves can resist the types of attacks that
have been plaguing SGX.  If we assume that Nitro enclaves are acceptably
secure, the next critical layer is our software framework.

A significant security aspect of our framework is its size; it is well
understood that complexity is the enemy of security.  Our framework counts less
than 700 lines of code and has four direct dependencies that are not maintained
by either us or the Go project.\footnote{The dependencies are chi~\cite{chi}
(provides an HTTP request router), nsm~\cite{nsm} (provides an interface to
interact with the Nitro hypervisor), vsock~\cite{vsock} (provides an API for the
VSOCK address family), and tenus~\cite{tenus} (provides an API to configure
Linux's networking devices).}  Four is worse than zero, but is still manageable
and reasonably easy to audit in its entirety.  We believe that our choice of
using Go and the deliberately small trusted computing base greatly reduces---but
does not eliminate!---the attack surface.

The highest layer in the software stack is the enclave application itself.  The
biggest security threat are side channel attacks and programming bugs---both
unintentional and intentional.  It is the application developer's
responsibility to prevent side channel attacks and write bug-free code.  As we
pointed out in Section~\ref{sec:limitations}, programming bugs can be
intentional, i.e., the service provider may deliberately introduce bugs that
leak sensitive information.  From the user's point of view, eternal vigilance
is therefore the price of security.

\subsection{Financial Cost}
\label{sec:cost}

Nitro enclaves do not incur any extra cost in addition to what the underlying
EC2 host costs---they can be considered a ``free'' extension to EC2.  Nitro
enclaves are however only available for select types of EC2 instances because
they require their own CPU and a minimum amount of memory, and those instance
types are pricier than the lowest tier that AWS offers.

We are currently working on deploying the IP address pseudonymization prototype
that we introduced in Section~\ref{sec:pseudonymization}.  We estimate that our
enclave is going to have to handle an average of 5,000 requests per minute,
coming from more than ten million clients.  Our test deployment uses a single
c5.xlarge EC2 host in the U.S. East region which costs \$0.17 per hour to
operate, amounting to approximately \$125 per month.

\subsection{Attestation Documents}
\label{sec:attestation-performance}

The fetching of attestation documents is a critical part of our framework's
overall performance.  We wrote a stress test tool that requests as many
attestation documents as it can over sixty seconds.  The tool is essentially a
minimal enclave application that requests attestation documents in a loop.  For
each attestation document, we asked the hypervisor to include an incrementing
nonce, to avoid any speedups by caching.  We were able to obtain approximately
900 documents per second, with each request taking a median of one millisecond
($s = 0.3\,\text{ms}$) to fetch the attestation document.\footnote{We performed
our measurements on a c5.xlarge EC2 host which comes with four CPUs and eight
GiB of memory.}

\subsection{Application Latency and Throughput}
\label{sec:end-to-end}

Next, we set out to measure the networking latency of the critical path, as
illustrated in Figure~\ref{fig:stress-test}.  In particular, we test the
latency of our TCP proxy, the VSOCK interface between EC2 and enclave, and a
minimal enclave application.
We measure latency in three separate setups, designed to help us understand how
much latency each component in our data flow adds:

\begin{figure}[t]
    \centering
    \input{sections/figures/stress-test}
    \caption{Our stress test tool tests the performance of our critical path,
    consisting of the TCP proxy, the VSOCK interface, and Go's HTTP stack in
    the enclave application.}
    \label{fig:stress-test}
\end{figure}

\begin{description}
  \item[Full:] This represents the full data flow as it would occur in
    production, i.e. client $\rightarrow$ TCP proxy $\rightarrow$ VSOCK
    interface $\rightarrow$ enclave application.

  \item[No proxy:] This setup does not contain the TCP proxy, i.e., the client
    talks to the VSOCK interface directly, i.e. client $\rightarrow$ VSOCK
    interface $\rightarrow$ enclave application.

  \item[Direct:] This setup does not contain the TCP proxy and the VSOCK
    interface.  Instead, the client directly talks to an application instance that is
    running \emph{outside} the enclave, i.e., client $\rightarrow$ application.
\end{description}

As part of our measurement setup, We first deploy the code from
Figure~\ref{fig:hello-world}---a minimalistic application that responds with
the string ``hello world'' upon receiving requests for the path /hello-world.
It's important to use a minimalistic application because we're only interested
in the latency that is caused by the components \emph{before} a request reaches
the enclave application.

To simulate clients, we use the HTTP load test tool Baton~\cite{baton}.  We run
Baton on the parent EC2 host and instruct it to send as many requests to the
TCP proxy as possible within 30 seconds, using 50 concurrent threads.  We had to
patch Baton's source code to add VSOCK support (to be able to send requests
directly to the enclave via the VSOCK interface) and to log latency
percentiles.  Note that our measurements constitute a \emph{lower bound} of the
latency that is achievable.  Real-world applications will exhibit higher latency
because clients send their requests over the Internet (which adds considerable
networking latency) and the enclave application is likely to be more complex
(which adds computational latency).

Figure~\ref{fig:latency-msmts} illustrates the results for our three test
setups.  The full pipeline is able to sustain 7,500 requests per second, with a
mean latency of 12.7 milliseconds.  Removing the proxy nearly doubles the
requests to 14,100 per second and lowers the mean latency to 6.5.  Finally, a
direct connection to the application---without proxy and VSOCK interface--once
again nearly doubles the number of requests, reaching 27,900 per second, with a
mean latency of only 3.2 milliseconds.  Figure~\ref{fig:latency-cdf} shows the
empirical CDF of the same latency measurements for our three test setups.

\begin{figure}[t]
    \centering
    \begin{tabular}{l r r r}
    \toprule
      Setup & Reqs/sec & Mean lat. (ms) & Max lat. (ms) \\
    \midrule
    Full & 7,500 & 12.7 & 56.0 \\
    No proxy & 14,100 & 6.5 & 52.0 \\
    Direct & 27,900 & 3.2 & 50.0 \\
    \bottomrule
    \end{tabular}
    \caption{Using 100 concurrent requests and 100,000 requests in total.}
    \label{fig:latency-msmts}
\end{figure}

\begin{figure}[t]
    \centering
    \input{sections/figures/latency-cdf}
    \label{fig:latency-cdf}
    \caption{The empirical CDF of the latency distributions of our three test setups.}
\end{figure}

Next, we measure the throughput that we can achieve over the VSOCK interface.
To that end, we use a VSOCK-enabled fork of the iperf3 performance measurement
tool~\cite{iperf-vsock}.  iperf3 measures the throughput of a networking link
using a client/server model.  In our experiment, we start an iperf3 server
instance inside the enclave and the corresponding client instance on the parent
EC2 host.\footnote{The command that we ran on the server was
``\texttt{iperf3 -{}-vsock -s}'' and on the client ``\texttt{iperf3 -{}-vsock -c
4}.''} The client then talks to the server via the VSOCK interface and
determines the maximum possible throughput.  In this setup, iperf3 measured a
throughput of 4.09 GBit/s.  For comparison, when running both the iperf3 client
\emph{and} server on the EC2 host---which effectively measures the
throughput of the EC2 host's loopback interface---we achieve 55.5 GBit/s of
throughput.

To develop intuition on the perceived network performance of Nitro enclaves, we
built an enclave application that acts as a SOCKS proxy.  We then configured a
browser to use this enclave-enabled SOCKS proxy and browsed HD videos on
YouTube.  We found that the experience was seamless: videos loaded quickly,
played smoothly, and there was no perceivable latency impact when browsing the
Web.  We believe that the high throughput and low latency, coupled with this
anecdotal user experience report suggests that our framework is suitable for
demanding and latency-sensitive networking applications.

\section{Limitations}
\label{sec:limitations}

We conclude the discussion of our framework by summarizing its limitations.

An obvious limitation is the reliance of our framework on Amazon, which acts as the root of trust.  We mentioned in Section~\ref{sec:trust-assumptions} that all parties must trust Amazon.  Note that this is not a new limitation of secure enclaves---SGX-based applications must trust Intel while TrustZone-based applications must trust ARM.  Despite the lack of alternatives, placing one's trust in a single corporation's proprietary technology is problematic.

Our system fundamentally relies on at least some users auditing the service provider's application that runs in a secure enclave.  Needless to say, not all users have the skills to audit the service provider's application and convince themselves that the code is sound.  In fact, even among the subset of users that are programmers, only a fraction may feel comfortable auditing source code for vulnerabilities.  So what are the non-programmers to do?  We envision users to congregate in forums where matters related to the service providers are discussed.  A tech-savvy subset of the users is going to organize code reviews and make public their findings.  Non-technical users may then trust other users that audited the source code, but this is no different from most other software: nobody audits all the software that they use, ranging from the kernel to the myriad of user space applications, even when source code is available.

The Underhanded C Coding Contest~\cite{underhanded-c} was about implementing benign-looking code that was secretly malicious.  The contest attracted numerous impressive submissions which showed that it can be surprisingly difficult to find bugs \emph{even if one knows} that there is a bug in a given piece of code.  Analogously, the service provider could try to hide subtle, yet critical bugs in the code to exfiltrate information from the enclave.  On top of that, if the service provider ever gets caught, it may have plausible deniability and pretend that the exfiltration bug was an honest programming error.  While we are unable to solve this class of attacks, we can mitigate it by keeping the trusted computing base in the enclave as small as possible.

\section{Framework Design}
\label{sec:design}

This section introduces the design of our framework.  We start by laying out the
involved parties and their respective trust assumptions
(\S~\ref{sec:trust-assumptions}), followed by an overview of our system
(\S~\ref{sec:overview}).  We then discuss the two major aspects of our
framework: the build system (\S~\ref{sec:build-system}) and the framework
itself~(\S~\ref{sec:framework}).

\subsection{Trust Assumptions}
\label{sec:trust-assumptions}

Our setting has three participants that have the following trust assumptions:

\begin{enumerate}
    \item The \emph{service provider} runs a service for its clients.  As part
      of its operations, the service provider wants to process sensitive client
      information.

    \item The \emph{client} is a user of the service provider.  It does not
      trust the service provider with its sensitive information and demands
      verifiable guarantees that the service provider will never see the
      client's sensitive information in plaintext.

    \item The \emph{enclave provider} makes available enclaves to the service
      provider.  Both the client and the service provider trust that the enclave
      provider's enclaves have the advertised security attributes of integrity,
      confidentiality, and verifiability.
\end{enumerate}

\subsection{Design Overview}
\label{sec:overview}

We begin with a short, informal overview of our system to provide intuition.
The subsequent sections are going to elaborate on this high-level picture.
The life cycle of an enclave application that uses our framework involves five
steps:

\begin{enumerate}
    \item The service provider implements a new service with the intention of
      running it in an enclave.  Once the implementation is finished, the
      service provider publishes the source code for its clients to audit, and
      runs the code in an enclave.  After booting, the enclave automatically
      obtains a CA-signed TLS certificate.

    \item Users audit the source code.  Once a user has convinced herself that
      the code is free of bugs, she compiles the code using the framework's
      deterministic build system, resulting in an image checksum.

    \item The client establishes an end-to-end encrypted network connection with
      the enclave, facilitated by the EC2 host blindly forwarding encrypted
      bytes.  Right \emph{after} establishing the TLS connection but
      \emph{before} revealing any sensitive information, the client provides a
      nonce and asks the enclave for an attestation document.

    \item The enclave receives the nonce and asks its hypervisor to generate an
      attestation document that should contain the client-provided nonce
      \emph{and} the fingerprint of the enclave's CA-signed certificate in
      addition to the usual image measurement checksums.  The
      resulting attestation document is returned to the client.

    \item The client performs various checks (see \S~\ref{sec:attestation} for
      details) and trusts the enclave if all checks pass.  The client is then
      convinced that it's communicating with the code that the user audited in
      the previous steps, and is willing to reveal her sensitive information to
      the enclave.
\end{enumerate}

\subsection{The Reproducible Build System}
\label{sec:build-system}

Only a small subset of the users will be skilled enough programmers to audit
the enclave's code for bugs.  We expect non-technical users to trust that other
users---or perhaps professional code audit companies---have studied the code
and pointed out potential bugs.  Once a user has convinced herself of the code's
correctness, she compiles the code to arrive at an image ID.  Crucially, we
need a \emph{deterministic mapping} between the code and its corresponding
image ID because the service provider and clients must agree on the image ID
that's running in the enclave.

The popular Docker tool does not offer a deterministic mapping because, among
other things, Docker records timestamps in its build process, causing subsequent
builds of identical code to result in different image IDs.\footnote{In essence,
a Docker image is merely a file system.  A Docker image is reproducible when
separate build processes arrive at the exact same file system, including meta
data like timestamps.}  To obtain reproducible builds, we replace Docker with
the kaniko tool~\cite{kaniko}.  Kaniko's main purpose is to build container
images from a Dockerfile while itself in a container, but we use kaniko because
it can do so reproducibly.  As long as the client and service provider use the
same enclave source code, Go version, and kaniko version, they can build
identical images---even when compiling the code on different platforms, like Mac
OS and Linux.  Equipped with a locally-compiled Docker image ID, the client is
now ready to interact with the enclave.

\subsection{Framework Components}
\label{sec:framework}

Having discussed how the client and service provider can independently compile
identical Docker image IDs, we now turn to the specific components of our
framework.  The following sections discuss how the framework
seeds its empty entropy pool (\S~\ref{sec:entropy});
how it communicates with the outside world (\S~\ref{sec:networking});
how it obtains a CA-signed certificate (\S~\ref{sec:cert});
how we facilitate remote attestation (\S~\ref{sec:attestation});
how enclaves can share their key material to allow for horizontal scaling (\S~\ref{sec:sync});
how to thwart side-channel attacks (\S~\ref{sec:side-channels}),
how to ingest secrets (\S~\ref{sec:secrets}), and
concludes with a simple example (\S~\ref{sec:example}).

\subsubsection{Seeding the Entropy Pool}
\label{sec:entropy}

Like many virtual machines, a Nitro enclave is an entropy-starved, sterile
environment without any periphery devices that help the kernel seed its entropy
pool.  To work around that, the Nitro hypervisor can provide randomness for the
enclave to seed its entropy pool.  Our framework automatically takes advantage
of that when it first starts (step~\ding{202} in Figure~\ref{fig:networking}),
so application developers never encounter function calls that block because of
insufficient randomness.

\subsubsection{Enabling Networking}
\label{sec:networking}

Recall from Section~\ref{sec:nitro} that Nitro enclaves have no networking
interface and are only able to communicate with their respective EC2 host.  Our
framework therefore needs proxying code that runs on the EC2 host and forwards
networking packets between clients and the enclave.  Figure~\ref{fig:networking}
illustrates the design of the networking architecture.

\begin{figure}[t]
\centering
\input{sections/figures/network-architecture}
\caption{Upon bootstrapping, the application first asks the hypervisor for
  randomness to seed its entropy pool (\ding{202}), followed by initiating an
  ACME session to obtain a Let's Encrypt-signed certificate (\ding{203}), after
  which Let's Encrypt probes the enclave and issues the certificate
  (\ding{204}).  Afterwards, clients can establish HTTPS connections with the
  enclave (\ding{205}) and the enclave can forward data to its back end
  (\ding{206}).  All of the application's ingress and egress  traffic is routed
  over a TCP proxy that translates between AF\_INET and AF\_VSOCK.  Egress
  traffic is reaches the Internet via a SOCKS proxy.}
\label{fig:networking}
\end{figure}

When the enclave first starts, it fetches a CA-signed certificate from Let's
Encrypt (cf. \S~\ref{sec:cert}) using the ACME protocol~\cite{acme-protocol},
which allows for the automated issuance of certificates.  To do so, it first
connects to Let's Encrypt's infrastructure via a SOCKS proxy (step~\ding{203}).
Let's Encrypt does not publish its endpoints' IP addresses, which is why we
cannot use point-to-point connections and have to rely on the flexibility of a
SOCKS proxy.\footnote{Our SOCKS proxy is available at
\url{https://github.com/brave-intl/bat-go/tree/nitro-utils/nitro-shim/tools/socksproxy}
and our TCP proxy is available at
\url{https://github.com/brave-experiments/viproxy}.} Let's Encrypt then verifies
that the enclave can answer queries on behalf of the requested domain name, and
issues a certificate to the enclave (step~\ding{204}).

Clients establish end-to-end encrypted TLS sessions to the enclave with the help
of a TCP proxy on the EC2 host that translates between AF\_INET (traditional,
IP-based sockets) and AF\_VSOCK (VSOCK-based sockets).  Note that the EC2 host
is blindly forwarding encrypted bytes, and cannot see what data the client and
the enclave are exchanging (step~\ding{205}).  In an optional, final step, the
enclave can send data to a back end (step~\ding{206}).

In case of an enclave compromise, we don't want the application to be able to
leak data to an attacker-controlled endpoint via the SOCKS proxy, which is why
we use an allow list on the SOCKS proxy.  It is the service provider's
responsibility to maintain the allow list.\footnote{Note that clients are unable
to remotely verify that the service provider correctly configured an allow list
because the SOCKS proxy runs on the EC2 host and not in the enclave
application.}  In a minimal application, the allow list consists of two
endpoints:

\begin{enumerate}
    \item The domain name acme-v02.api.letsencrypt.org to interact with Let's
      Encrypt's infrastructure.
    \item The IP addresses or domain names of whatever back end machine the
      enclave needs to talk to.
\end{enumerate}

If an attacker discovered a remote code execution bug in the enclave application
and uses the bug to make the enclave establish a connection to any domain name
that is not part of the allow list, like evil.com, the SOCKS proxy is going to
reject the connection.

\subsubsection{End-to-end Secure Channel}
\label{sec:cert}

Having established how the enclave can send and receive network packets, we now
turn our attention to secure channels; specifically: how can a client rest
assured that it is talking to audited enclave application code, without taking
advantage of an existing trust relationship?

The application can register arbitrary HTTP handlers that are accessible to the
outside world to process data and provide services.
Our framework provides a secure channel based on HTTPS, i.e., we make it
possible for a client to establish an HTTPS connection with an enclave in a way
that the TLS connection is terminated inside the enclave. Clients can use this
channel to access the application without revealing data to third-party
observers, or to the service provider, outside of the specific ways the enclave
application permits.

Once the enclave has initialized its entropy pool, it obtains an HTTPS
certificate that allows clients to establish end-to-end encrypted session with
the enclave.  Crucially, the HTTPS certificate \emph{lives and dies} inside the
enclave and its private key cannot be extracted (or injected) by the service
provider because enclaves are sealed at runtime.  Our framework allows for both
the creation of a self-signed or a CA-signed certificate.  If a self-signed
certificate is desired, the framework creates and signs a certificate for a
given FQDN.  To get a CA-signed certificate, the framework uses Let's Encrypt's
ACME protocol because it allows for the generation of a certificate with no
human interaction.  In that case, the enclave initiates an HTTP-01
challenge\footnote{ACME supports multiple challenge types, with HTTP-01 being
the most common one~\cite{http-01}.  In HTTP-01, the ACME infrastructure
provides the client with a token, which must subsequently be available at a
pre-defined path on the client's Web server.} connection with Let's Encrypt's
infrastructure via our SOCKS proxy (cf.  Figure~\ref{fig:networking}), and
subsequently expects an incoming connection from Let's Encrypt to port 80, which
the EC2 host forwards to the enclave.  Note that the EC2 host can also obtain a
CA-signed certificate for the same FQDN because the enclave and the EC2 host
share an IP address.  This is however of little use to the EC2 host as we will
show in the next section.

\subsubsection{Remote Attestation}
\label{sec:attestation}

By default, Nitro enclaves only allow for local attestation.  We now discuss how
we allow clients to remotely retrieve and verify an enclave's attestation.
After the client establishes an HTTPS connection with the enclave, it needs to
know that (\emph{i}) the TLS connection it just established is terminated inside
the enclave (instead of by the EC2 host) and (\emph{ii}) the enclave is running
the code that the user audited in the previous step.  To that end, the client
requests the enclave's \emph{attestation document}---a hypervisor-signed
document that attests to the container image ID that the enclave is running.
Enclaves communicate with the hypervisor via the ioctl system call, which makes
use of /dev/nsm, a device that is only available inside a Nitro enclaves.  To
request an attestation document, the client provides a \emph{nonce}---a 160-bit
random value---whose purpose is to prevent the service provider from replaying
outdated attestation documents.  Phrased differently, the client provides a
nonce to convince itself that it's talking to a live enclave.  In practice,
clients make the following HTTP request to obtain an enclave's attestation
document:

\begin{lstlisting}[numbers=none,basicstyle=\small\ttfamily]
GET /attestation?nonce=8083...23b7 HTTP/1.1
\end{lstlisting}

The enclave receives the request through the TCP proxy, asks the hypervisor to
include the nonce \emph{and} the fingerprint of the enclave's X.509 certificate
in the attestation document, and sends the resulting attestation document to the
client.  By asking the hypervisor to include the certificate fingerprint in the
attestation document, we effectively bind a TLS session to an enclave, which is
key to assuring the client that it is in fact talking to an enclave.  Upon
receiving the attestation document, the client then verifies the following in
order:

\begin{enumerate}
    \item The attestation document is signed by the AWS PKI whose public key is
      known to all parties.
    \item The challenge nonce is part of the attestation document.
    \item The fingerprint of the enclave's X.509 certificate from the TLS session is part of the
      attestation document.
    \item The enclave's image ID is identical to the image ID that the client
      compiled locally.
\end{enumerate}

Only if all four conditions hold is the client convinced that it is talking to
an enclave running the code that the client audited, and that the TLS connection
is terminated by the enclave.  Note that the EC2 host is able to intercept HTTPS
connections with its own CA-signed certificate but clients will only trust the
EC2 host if (and only if) it can present an attestation document that is valid
for the enclave image, which it can't because it is unable to spoof the AWS PKI
signature that authenticates the attestation document.  The only way for the EC2
host to obtain such an attestation document is to spawn an enclave that runs the
exact code that the client is expecting---and it already is doing exactly that.
Now that the client has established a trust relationship with the enclave, it is
ready to reveal sensitive information to the enclave.

While attestation documents can be generated quickly and in rapid succession
(cf. \S~\ref{sec:attestation-performance}), they do require an extra round trip
between the client and the enclave before the client is willing to reveal
sensitive information: the client first provides a nonce to the enclave, the
enclave responds with an attestation document, and only after the client
verified the document is it willing to reveal its sensitive information.  To
eliminate unnecessary future round trips, clients should use TLS session
resumption once they have verified the enclave's attestation document.  The
service provider is unable to see the secret key material that protects the TLS
session between client and enclave, so it is safe to re-use a once-established
TLS session and forgo the unnecessary round trip.

\paragraph{Manual Client-side Verification}

In general, we envision that remote attestation is handled transparently by
client software, without involving the user.  In some cases however, users may
wish to manually verify an enclave.  Even for developers, remote attestation is
a complex process that is difficult to understand and work with.  To make
matters more complex, in our setting end users are expected to conduct remote
attestation.  We therefore made a careful effort to abstract away technical
details.  A user wishing to remotely verify an enclave essentially asks herself
``does the enclave that's exposed at a given URL run the source code that I just
audited?''  We built a tool set that reduces the process to the running of a
Makefile,\footnote{The source code is available at:
\url{https://github.com/brave-experiments/verify-enclave}.} i.e.:

\begin{lstlisting}[numbers=none,basicstyle=\small\ttfamily]
$ make verify CODE="/path/to/enclave/code/" \
              ENCLAVE="https://example.com/attest"
\end{lstlisting}

The first argument, \texttt{CODE}, points to the directory containing the source
code that the enclave is supposedly running, and the user audited.  The second
variable, \texttt{ENCLAVE}, points to the URL endpoint of the enclave that the
user's client is connecting to.  When the user runs this command, the Makefile
deterministically compiles the given source code to obtain its image ID, asks
the enclave for an attestation document, verifies the document, and ensures that
the attestation document is for the image ID that was compiled in the first
step.  If all checks pass, the tool informs the user accordingly.

\subsubsection{Sharing Key Material}
\label{sec:sync}

Recall that enclaves are essentially sealed at runtime, preventing anyone
(including both Amazon and the service provider) from extracting key material
that was generated inside the enclave.  While this is a desirable property, it
complicates horizontal scaling.  If a single enclave is unable to handle the
service provider's traffic load, one must scale horizontally by starting new
enclaves.  In some applications, it is unacceptable for each enclave to use
distinct key material.  Instead, enclaves must synchronize their key material,
so they appear to the outside world like a single machine.

While it is possible to build key synchronization using tools like the AWS key
management service (KMS),\footnote{One could encrypt the keys using a KMS
policy that dictates that only enclaves are allowed to decrypt it, and store
the encrypted key in a location that all enclaves can access, e.g., an S3
bucket.} we refrain from using KMS because there is no straightforward way for
users to verify that the service provider is using KMS as promised.  We
therefore devise a new protocol that enables key synchronization without having
to rely on external services.

We solve this problem in two steps: \emph{discovery} and
\emph{synchronization}.  First, enclaves must be able to discover each other,
i.e., learn each other's IP addresses.  Then, enclaves can establish
connections to each other and initiate key synchronization.  Our protocol
dictates that when a new enclave bootstraps, it first tries to discover
already-existing enclaves.  If there are none, the enclave knows that it is the
``origin'' enclave; it generates new key material and is prepared to share it
with future enclaves.  If however it discovers other enclaves, the new enclave
establishes a connection to another randomly-chosen enclave and initiates key
synchronization.  Crucially, key material is only shared after \emph{mutual
attestation}, i.e., the original and subsequent enclaves verify each other, and
only exchange key material if remote attestation succeeds.  Key synchronization
happens in three steps, as illustrated in Figure~\ref{fig:key-synchronization}.

\begin{figure}[t]
  \centering
  \input{sections/figures/key-synchronization}
  \caption{When a new enclave bootstraps, it discovers existing enclaves by
    obtaining the DNS SRV record for its own, hard-coded FQDN.  The enclave then
    initiates key synchronization by first requesting a nonce.  Then, the new
    enclave requests the origin enclave's key material by submitting its own
    attestation document, followed by receiving the origin enclave's attestation
    document, which contains encrypted key material.}
  \label{fig:key-synchronization}
\end{figure}

\begin{enumerate}

  \item Once a new enclave is spun up, it queries the DNS SRV record of the FQDN
    that is hard-coded in the enclave, e.g., example.com.  The DNS resolver will
    return the record, containing a list of enclaves that are already running and initialized.
    The new enclave picks a random enclave from the list and initiates key
    synchronization.

  \item The new enclave asks the existing enclave for a random nonce,
    $\textrm{nonce}_o$.  Each enclave caches $\textrm{nonce}_o$ for one
    minute.

  \item The new enclave now requests the key material from the existing enclave.
    As part of the request, it provides its attestation document that contains
    $\textrm{nonce}_o$ (to prove freshness to the existing enclave);
    $\textrm{nonce}_n$ (the existing enclave is expected to add this nonce to its
    attestation document); and $K_n$ (a public key to which the key material
    should be encrypted).  Upon receipt of the new enclave's attestation
    document, the existing enclave verifies the attestation document's signature
    and ensures that the new enclave is running the same code, i.e., the measured checksum
    value that uniquely identifies the enclave image is identical.  Once the existing
    enclave is convinced that it is dealing with a genuine new enclave, it
    creates an attestation document by including $\textrm{nonce}_n$ (to prove
    freshness to the new enclave) and $\textsf{Enc}(K_n, s)$---the key material
    $s$ is encrypted using the public key that the new enclave provided in the
    request.  Finally, the new enclave verifies the attestation document,
    decrypts the key material, and uses it to finish bootstrapping.

\end{enumerate}

Needless to say, the security of key synchronization is paramount.  As an
optional first layer of defense, synchronization should be configured to use a
private network segment limited to inter-enclave communication, such as the
internal network that is part of a Kubernetes cluster that is managing scaling
for the application.  While optional, Kubernetes is an attractive component in
our setting considering that enclaves are essentially compiled Docker images.
The second and main layer of defense is the fact that an enclave has to provide
a valid attestation document before the origin enclave reveals its key material.
As long as the origin enclave knows that an identical and authentic copy of
itself is asking for key material, it will readily provide it.

\subsubsection{Side-channel Attacks}
\label{sec:side-channels}

The enclave's parent EC2 host cannot see \emph{what} clients send to the enclave
but it can see \emph{how much} clients send and \emph{how long} it takes the
enclave to process data.  The EC2 host can exploit these side channels to learn
more about the client's confidential information and computation.  While such
side channels must be avoided, our framework is not the place to do so.
Instead, it is the application developer's responsibility to identify and
address this class of attacks.  Section~\ref{sec:applications} introduces two
applications and discusses side channel attacks in their respective setting.

Similarly out of scope are programming bugs in the enclave application.  Memory
corruption bugs may be more difficult to exploit in an enclave
application\footnote{The untrustworthy operating system (that may be under the
attacker's control) is prohibited by hardware to read the enclave application's
memory or registers in clear text, which forces the attacker to operate
blindly.} but Lee et al. adapted a return-oriented programming attack against
SGX to show that such attacks are practical~\cite{Lee2017a}.

\subsubsection{Ingesting Secrets}
\label{sec:secrets}

A key design requirement of our framework is that users can audit and verify the
code that is running inside an enclave, which means that the service provider is
unable to hide any software configuration from the user.  Service providers can
work around this shortcoming by implementing HTTP handlers that take as input
arbitrary data, and use it to update the enclave's state.  Consider a system
that takes as input client IP addresses, anonymizes them, and forwards the
anonymized addresses to a back end (cf. \S~\ref{sec:pseudonymization}).  The
service provider now wants to compare submitted IP addresses to a confidental
deny list.  However, if the deny list is hard-coded in the freely available
enclave application, it is readily visible to anyone.  The service provider can
solve this problem by adding to the enclave application a new HTTP handler that
takes as input the confidential data it seeks to protect from the users' eyes.
Once the enclave is running, the service provider loads the confidential data
at runtime, by calling the end point.  To prevent users from submitting bogus
data, the endpoint could hard-code the service provider's public key and only
accept data that carries a valid signature of the service provider's private
key.

This technique for ingesting secrets into an enclave's runtime is flexible---so
flexible, in fact, that the service provider could abuse it to ingest code at
runtime, which would nullify the enclave's verifiability requirement.  Vigilant
users would never trust an enclave whose code can change at runtime.  We
therefore argue that an HTTP handler for the purpose of injesting secrets must
be constrained to a point that only data of a well-defined type can be injested.

\subsubsection{An Example}
\label{sec:example}

Figure~\ref{fig:hello-world} illustrates an example of a simple ``hello world''
application.  The code initializes a new enclave struct (line 16), followed by
adding a handler that processes requests for \texttt{GET /hello-world} (line
24).  Finally, the application starts the enclave using a function call that
does not return (line 27).

\begin{figure}[t]
\begin{lstlisting}[language=go]
package main

import (
    "fmt"
    "log"
    "net/http"

    nitro "REDACTED"
)

func handler(w http.ResponseWriter, r *http.Request) {
    fmt.Fprintln(w, "hello world")
}

func main() {
    enclave := nitro.NewEnclave(
        &nitro.Config{
            FQDN:    "example.com",
            Port:    8080,
            UseACME: true,
            Debug:   false,
        },
    )
    enclave.AddRoute(http.MethodGet,
                     "/hello-world",
                     handler)
    if err := enclave.Start(); err != nil {
        log.Fatalf("Terminated:
    }
}
\end{lstlisting}
\caption{An example of a simple enclave application which registers an HTTP GET
  handler for the path /hello-world (line 24) and, when accessed, responds with
  the string ``hello world'' in the response body (line 12).}
\label{fig:hello-world}
\end{figure}

The configuration object (line 17) consists of four fields.  The first field
determines the enclave's FQDN, which is required when obtaining an X.509
certificate.  The port is listened on by the enclave via the VSOCK interface.
It is the EC2 host's responsibility to forward incoming traffic to
this port.  The third field determines if the enclave should use Let's Encrypt's
ACME protocol to obtain a CA-signed certificate at runtime.
The last flag instructs the framework to print debug information.  Note that
this is only useful when the enclave is invoked in debug mode, which disables
remote attestation.

\section*{Acknowledgment}

The authors would like to thank...

\section{Related Work}
\label{sec:related-work}

Arnautov et al. present in their OSDI'16 paper a mechanism that allows Docker
containers to run in an SGX enclave~\cite{Arnautov2016a}---conceptually similar
to Nitro enclaves, which are effectively compiled Docker images.
In their 2022 arXiv report, King and Wang~\cite{King2022a} propose HTTPA---an
SGX-based extension to HTTP that makes a Web server attestable to clients.  Our
framework also allows for attestable Web services, but without modifications to
HTTP.

\paragraph{Applications of Enclaves}

Researchers have proposed numerous and diverse enclave-enabled systems, ranging
from DeFi oracles~\cite{Zhang16a}, to health apps for
COVID-19~\cite{Mailthody21a}, to networking middleboxes~\cite{Han17a}.  Despite
avid interest in academia, large-scale, real-world deployments of enclaves are
sparse.  In 2017, the Signal secure messenger published a blog post on private
contact discovery~\cite{Marlinspike17a}, which makes it possible for Alice to
discover which of the contacts in her address book use Signal without revealing
her contact list.  The Signal team accomplished this by relying on an SGX
enclave that runs the contact discovery code.  Two years later, in 2019, the
Signal team built its ``secure value recovery'' feature on SGX as
well~\cite{Lund19a}.

\paragraph{Frameworks for Enclave Development}

To facilitate working with enclaves, several frameworks have emerged that
abstract away complicated and error-prone low-level aspects of enclaves.
Examples are Asylo~\cite{asylo} and Open Enclave~\cite{openenclave}---both
libraries are implemented in C/C++ and are hardware agnostic, meaning that the
``enclave backend'' can be switched from, say, TrustZone to SGX.  While
frameworks render enclave development more convenient, memory unsafe languages
like C and C++ make it dangerously easy to introduce memory corruption bugs
that jeopardize the security of the enclave~\cite{Lee2017a}.  Cognizant of
this issue, Wang et al. implemented a performant Rust layer on top of Intel's
C++-based SGX SDK, making it possible to develop memory-safe applications in
SGX~\cite{Wang2019a}.

Our framework is built in the memory-safe Go programming language, which
eliminates an entire class of bugs that could jeopardize the security of
enclave applications, and unlike Asylo and Open Enclave, our framework only
supports Nitro enclaves because the security guarantees of a framework are only
as strong as the underlying enclave hardware, and in the case of Intel, ARM,
and AMD, side channel attacks are a severe concern.

\paragraph{Attacks Against Enclaves}

Enclaves based on Intel's SGX technology share a CPU with untrusted code, which
raises the flood gates for side channel attacks.  Consequently, attacks have
taken advantage of
speculative execution~\cite{VanBulck2018a,VanSchaik2021a},
branch ``shadowing''~\cite{Lee2017b},
the interface between SGX and non-SGX code~\cite{Bulck19a},
software faults~\cite{Murdock2020a},
shared caches~\cite{Brasser2017a},
and memory management~\cite{Wang2017a}.
Despite the considerable number of practical attacks, there is opportunity to
strengthen SGX against side channel attacks.  Oleksenko et al. introduce in
their ATC'18 paper a system that protects unmodified SGX applications from side
channel attacks by executing the enclave code on a CPU separate from the
untrusted code.  Note that this is the default for Nitro enclaves.

For a comprehensive overview of attacks against SGX, refer to Fei et al.'s
survey~\cite{Fei2021a} and Nilsson et al.'s arXiv report~\cite{Nilsson20a}.

Among all currently-available commodity enclaves, Intel's SGX has received the
most attention from academia but ARM's TrustZone and AMD's SEV have not been
spared and share SGX's conceptual security flaws.  In a CCS'19 paper, Ryan
demonstrates an attack that exfiltrates ECDSA private keys from Qualcomm's
implementation of a hardware-backed keystore which is based on
TrustZone~\cite{Ryan2019a}.  Similarly, Li et al. showed in a USENIX
Security'21 paper how an attacker can exfiltrate private keys from AMD
SEV-protected memory regions.  In a CCS'21 paper, Li et al. showed how an
attacker-controlled VM can read encrypted page tables, and how an attacker can
create an oracle for encryption and decryption.

While Nitro enclaves are still young and have received nowhere near the same
scrutiny as SGX and friends, we believe that their dedicated hardware resources
provides stronger protection from side channel attacks than enclaves
that are based on shared CPU resources.

\section{Background}
\label{sec:background}

This section provides an overview of secure enclaves in general
(\S~\ref{sec:enclaves}) and AWS's implementation in particular
(\S~\ref{sec:nitro}).

\subsection{Secure Enclaves}
\label{sec:enclaves}

Computers operate on data that is at rest, in transit, and in use.  We have
well-understood and practical ways to protect data at rest (e.g., full disk
encryption) and in transit (e.g., TLS) but only limited solutions for data that
is in use.  Cryptography provides solutions in the form of fully homomorphic
encryption (FHE) and secure multiparty computation (MPC) but for many
applications, those building blocks remain too slow and cumbersome.  Trusted
execution environments---in particular in the form of ``secure
enclaves''---provide an alternative that is rooted in hardware and code.  Unlike
FHE and MPC, enclaves perform at native (or near-native) execution speed because
they are general-purpose computing environments that are not limited to the
computation of carefully designed functions.  Conceptually, enclaves are
isolated execution environments that are shielded off from a computer's main
execution environment, which runs the untrustworthy (from the enclave's point of
view) operating system.  Enclaves offer various security properties but in the
context of this work, we rely on the following three:

\begin{description}
  \item[Confidentiality] An unauthorized entity must not be able to observe the
    data that an enclave is computing.

  \item[Integrity] An unauthorized entity must not be able to modify the data
    that the enclave is computing on, or the code it is running.

  \item[Verifiability] A separate entity must be able to verify if the enclave
    is running the code that its operator claims it is running.
\end{description}

Modern CPUs of major hardware vendors implement secure enclaves: Intel has SGX,
ARM has TrustZone, and AMD has SEV.  A frequent critique of these industry
efforts focuses on their proprietary nature. The community has a conceptual
understanding of the mechanisms behind enclaves but their exact hardware
implementation is not disclosed, which served as motivation towards an open
source enclave~\cite{Lee20a}.  In practice, enclaves promise to be useful in
situations where a system must process sensitive data while simultaneously be
shielded off from the complexity (and subsequent insecurity) of general-purpose
computers.

\subsection{AWS Nitro Enclaves}
\label{sec:nitro}

In this work, we build on top of AWS's Nitro enclaves.  Nitro enclaves are
isolated and constrained virtual machines that run alongside an EC2 instance
that is responsible for starting the enclave, and communicating with it.
Crucially, an enclave does not share hardware resources with its parent EC2
image; it is guaranteed to have its own CPU and memory which is
isolated from the parent EC2 image by the same hypervisor that isolates EC2
instances from each other.
As far as computing resources go, Nitro enclaves are essentially an independent
computer, with its own operating system, CPU, and memory, but \emph{without} a
networking interface or persistent storage.  By design, the enclave's network
traffic must go through the parent EC2 instance, constrained to a minimal VSOCK
interface~\cite{vsock}. Originally proposed for communication between a
hypervisor and its virtual machines, AWS repurposed the VSOCK interface to serve
as communication channel between an enclave and its parent EC2 instance.  From a
developer's point of view, the VSOCK interface is a point-to-point interface
connecting the two.  On the address layer, 32-bit
context IDs take the role of IP addresses in VSOCK interfaces.  For example, the
enclave may have context ID 4 while its parent EC2 instance may have context ID
3.  On the transport layer, one can use the same protocols that one can use over
the IP-based address family; namely TCP, UDP, etc.

\begin{figure}[t]
  \centering
  \input{sections/figures/dev-workflow}
  \caption{The development workflow for compiling enclave applications.
  Docker's command line tool compiles application source code into a Docker
  image, which is then compiled to an enclave image file using the nitro-cli
  command line tool.}
  \label{fig:dev-workflow}
\end{figure}

Figure~\ref{fig:dev-workflow} illustrates the development workflow for enclave
applications: the workflow begins with the creation of a Docker image that
contains the application that will run in the enclave.  Using Amazon's
nitro-cli command-line tool, the developer then compiles the container image to
an enclave image file (EIF).  The compilation process results in a number of
\emph{measurement checksums} that uniquely identify the image itself, its
kernel, and application.  As we will discuss later in the paper, these
measurements are key to the remote attestation process.
Once the EIF is ready, the developer starts the enclave on an EC2 instance
using the nitro-cli command-line tool.  The only way for the EC2 instance to
exchange data with the enclave is via the VSOCK interface.

redpajama_set_name: RedPajamaArXiv


During the week, we are consumed with so much (work, errands, etc.) that by the time the weekend comes, we are looking for a way to relieve ourselves of our hectic schedules and everyday life, period. Well, the relief now comes in the form of a new local club and sports bar, Rosetta's Live Music and Comedy. Located on 1335 Celanese Rd., Rock Hill, SC, you can visit anytime between the operating hours of 11am-2am. I had the chance to visit this new establishment on Saturday and was HIGHLY impressed.
Big Daddy Burger (6 patties)- $12.50….with fries, $16.50- Take the Rosetta's Challenge and try to down this bad boy in 2o mins! Chicken sandwich, hot dogs, chicken strips, wings, chili fries, fried green tomatoes, fried okra, onion rings, fish and hush puppies, salad ($6.99), hoagies (turkey, ham, roast beef, salami, Philly cheese, Trios sandwich)- hoagies come in either 6-in or 12-in.
If you live in Rock Hill, any of the surrounding cities, or are simply visiting the area, I would definitely recommend this as a place to gather with friends. Not to mention, there are a ton of menu items so feel free to stop in for a quick bite to eat! Don't believe me, check it out for yourself! I dare you!
I stopped by Rosetta's for fried green tomatoes and they were delicious, I haven't been at a nightlife event but I think I would like too. Wish I could be kept updated with the happenings on a weekly basis being single and looking for a place to hangout, this may really be the spot for me.


How boring it can sometimes be to lead an ordinary life of an ordinary person! Are you familiar with something like this? Do you feel from time to time that you are a little bit freaky?
It is hard to find a person, who will become your soul mate. But it`s even harder to be in a couple with this person! If you have relationships with anyone, you`ll agree with this statement without any hesitation!
Not all people are lucky to have best friends or at least good friends! If you're among those happy people who have the good fortune to meet a soul mate, you know for sure that friendship is a fragile thing.
Almost all of you will agree that having a boyfriend is always fun, although sometimes it can be a little bit exhausting and problematic! You love him, and he loves you, but something often disturbs and makes you crazy. Is it true?
Don't like Thursdays? Many people don't! And it's not a big surprise! Thursday is only another day of the week. You still have to get up early in the morning and go to work or mind your own business.
Have you ever heard the phrase "A good beginning makes a good ending"? It`s definitely about your morning! All people at least once think "Oh! How awful this morning is". And it`s not a surprise! Because they haven`t look through funny good morning memes!
Have you ever missed anyone? Then you`re familiar with the feeling of apathy, great emptiness and loneliness!
Who is your wife? She is your most faithful friend, an incredible lover, a supporting sister, and your biggest fan! It doesn't matter what things happen in your life, she is always near and ready to give you a shoulder to cry on.


Next I got a sense of the Inbetweens and the Breakdowns by searching for what pose would lead to the next, all while still keeping in mind the timing.
At this stage I changed the curves from stepped to spline only in the first half to get a better sense of the animation in bite size pieces.
In this stage of the animation I have Completely changed the curves to spline and adjusted the timing so that there would be holds in the right places, I also offset some of the keyframes so that there is some overlap action specifically on her hips, shoulders, and hair. I also tweaked the shaders to get it ready for render.
This is the final Render using Arnold with Arnold Shaders on Maya each frame took in average 5 min to render and the total animation is 71 frames long, in total it took about 5 hours to render but I think I may have gone a little nuts with the render settings.


This poker site recently launched, but the site is not technically brand new. Ignition is simply the rebranding of the former poker site known as Ignition. The purpose of the rebrand was to allow poker players from the United States, while Ignition specializes in casino and live betting. Players from the United States can compete against each other and the poker tables are full day and night. In addition to poker. Ignition allows players to have one account for use on poker and casino games.
One of the nice things about Ignition is the fact that while it is a new site the people running it have years of experience working with online gaming. As far as popularity goes, it is difficult to determine. One of the benefits that Ignition has is that the Bovada site was already popular with American players, and they simply transferred their U.S. poker player accounts over to the Ignition site. However, many United States players may not realize that there are still places where they can legally play poker online.
The Bovada brand has done pretty well keeping an American audience and there is no doubt that Ignition will do exactly the same. The software and games do not change.
As a way to attract players to the site, Ignition does a very good job of offering great sign up bonuses as well as attractive bonuses for their players. The site is currently offering a 100% matching sign up bonus up to $2,000 for all the players who make their first deposit on the site.


text:
public class CoordPair {

}

redpajama_set_name: RedPajamaGithub


da steckt Entwicklung drin, kürzer geht es nicht in solcher Verständlichkeit..
I like it for that!
yes, yes, YES! That's my kind of breakfast. ;) Ask my husband! ha.
Oh Ralf, I love this!!
I like this. You might try it without "crunchy." Mark Twain on the adjective: "When in doubt leave it out."
Thanks a lot everybody. And yes, _m, evrything is ok. But work and preparinf haiku nrw 2.0 took a lot of time. We just had the meeting and a great time. So I hope to save some hours now fpor blogging and commenting. Indeed: I do miss both.


text:
Scigliano est une commune de la province de Cosenza, dans la région de Calabre, en Italie.

Administration

Hameaux
Calvisi, Lupia, Serra-Petrisi, Cupani, Diano, Porticelle-Agrifoglio, Celsita, Tasso

Communes limitrophes
Altilia, Carpanzano, Colosimi, Pedivigliano

Personnalités
 Vitaliano Camarca (1921-1969), journaliste, éditeur et typographe italien, est né à Scigliano.

Notes et références

Commune dans la province de Cosenza

redpajama_set_name: RedPajamaWikipedia


IQS Directory provides an extensive list of gas furnace manufacturers and suppliers in Delaware. Utilize our website to review and source gas furnace manufacturers with our easy-to-use features which allow you to locate gas furnace companies that will design, engineer, and manufacture gas furnaces for your exact specifications. Our request for quote forms make it easy to connect with leading gas furnace manufacturers. View company profiles, website links, locations, phone number, product videos, customer reviews, product specific news articles and other production information. We are a leading manufacturer directory who will connect you with the right manufacturers whether you are looking for heat treating furnaces, industrial furnaces, or blast furnaces.
We are producers of furnaces, kilns, & ovens. Nabertherm offers over 500 models of industrial furnaces ranging from bench-top to drive-in. Suited to your particular efficient requirements with maintenance & ease, our furnaces can be delivered on-time & at a reasonable price. In business for 6 decades! Gas Furnaces in Delaware.
We buy and sell industrial heat treating furnaces and industrial baking ovens worldwide, including walk in ovens, cabinet ovens, heat treat furnaces, induction heaters, vacuum furnaces and internal oil quench furnaces. We have the largest database of available heat treating equipment in the world. Check out our inventory by visiting our website today! Gas Furnaces in Connecticut.
Furnace Source is a manufacturer and distributor of industrial furnaces. Furnace Source offers custom manufacturing, remanufacturing, engineering capabilities, and research and development capabilities. Manufactured products include sintering furnaces, vacuum furnaces, and medical process equipment. Gas Furnaces in Connecticut.
Morgan Molten Metal Systems is a global manufacturer and distributor of crucibles, foundry products, and industrial furnaces. In business for over 150 years, we offer quality production and servicing of electric furnaces, gas furnaces, as well as retrofit kits to meet your specific needs. Gas Furnaces in Connecticut.
Noble is committed to using the highest quality materials to design a customized furnace that meets the needs of your application. For over 40 years, we have served clients both across North America and across the world. No matter the size or location of your company, our team's promise is to give specialized attention to the details of every job we take. For more details on what we can do for your business, call or visit our website today! Gas Furnaces in Connecticut.
Corbett Industries specializes in industrial furnaces, electric furnaces, gas furnaces, high temperature furnaces, metal melting furnaces, dual chamber furnaces and car bottom furnaces. We serve the electronic, textile, pharmaceutical and packaging industries. Gas Furnaces in New Jersey.
First Choice... Best Choice... Every Time. We offer industrial furnaces, gas furnaces and furnace components. As a premier metal fabricator and furnace manufacturer, we are capable of providing you with every conceivable type and nearly every size of furnace or its components. Gas Furnaces in New Jersey.
Do you need vacuum induction melting furnaces or vacuum heat treating furnaces that will provide precise, repetitive performance, archive process statistics and have more production up-time? At PV/T, we have a full range of custom and standard vacuum furnaces available to our customers. Gas Furnaces in New Jersey.
Since 1996, Elnik's MIM 3000 Batch gas furnaces are the standard for processing MIM and PIM parts. Process under laminar gas flow in H2, N2 and Ar. Elnik also provides high-quality high temperature vacuum furnaces for Sintering, Heat Treating, Brazing and many specialized applications. Gas Furnaces in New Jersey.
T-M Vacuum has been manufacturing vacuum furnaces & ovens, thin film deposition systems and atmospheric enclosures (glove boxes) for 40+ years. We produce vacuum furnaces in a range of sizes for thermal processing applications with furnace capabilities of reaching temperatures as high as 2000C & oven capabilities as high as 600C. Our design & production techniques ensure a maximum system life. Gas Furnaces in New Jersey.
UNIQUE/PERENY—a division of HED® International, Inc. and combination of the former Unique Kiln Company & the Pereny Furnace Company—continues to design and manufacture superior kilns, furnaces, ovens and other thermal systems. Our products are sought after by well-respected industrial, research, educational and government institutions located throughout the world. We design what others cannot. Gas Furnaces in New Jersey.
With almost 60 years of experience as a furnace manufacturer, Casso-Solar specializes in tubular quartz furnace heaters, electric furnaces and gas furnaces. Our items serve the electronics, glass, paper converting, product finishing, textile manufacturing and the plastics and film industries. Gas Furnaces in New York.
As an industrial furnace manufacturer, we know that one model is not suitable to all. That's why we make a variety of sizes and types of furnaces — melting, high-temperature salt bath, rectangular, round, roll-out, Buzzer Fire-Box™ and heat treating furnaces. We've been in business since 1911. Gas Furnaces in New York.
Harper International supplies the aerospace and automotive industries with electric furnaces, high temperature furnaces, batch furnaces, atmosphere furnaces, gas fired furnaces and ceramic furnaces. We have been providing innovative industrial furnace solutions to industries for over 70 years. Gas Furnaces in New York.
Our gas furnaces are manufactured with our customers in mind. JPW Industrial Ovens & Furnaces manufactures standard and custom made gas furnaces and other furnaces. We are dedicated to providing high quality products and excellent customer service. Our products are used in a variety of industries like aerospace, food, general manufacturing, and more! For more information about our products, call us today or visit our website! Gas Furnaces in Pennsylvania.
Through its expert Lindberg/MPH brand and reliable and value priced Blue M line, TPS is a global leader in the design, engineering, manufacture and aftermarket support of industrial furnaces. Whether it's Crucible, Lab Box, Tube, Chamber Utility Box, Element Box, Hot Stamping/Press Hardening, Pit, Integral Quench, Conveyor, Continuous Process, Vacuum, Gantry Line, Walking Beam or a range of Non Ferrous Melting and Holding options, we have an industrial furnace that will meet your application. Gas Furnaces in Pennsylvania.
We are your source for gas furnaces! Our company boasts years of experience designing and building high temperature production furnaces. Our furnaces are used in applications such as sintering, debinding, pre-sintering, and annealing as well as many others. We are dedicated to offering exceptional customer service at all times in hopes of meeting or exceeding customer expectations. To learn more call us today! Gas Furnaces in Pennsylvania.
At Abell Combustion, we can engineer, install and supply infrared heaters, cure heaters, air turnover units, unitary infrared heaters, infrared comfort heaters, gas infrared tube heaters and more. We are a company that works together with our customers to find the perfect solutions for their needs. Gas Furnaces in Pennsylvania.
Applied Test Systems provides industrial furnaces, controlled-atmosphere furnaces and high-temperature furnaces. Heat treating furnaces included are a variety of different types such as tube furnaces, box furnaces and split-tube furnaces. Our furnaces are competitively priced and unmatched in their quality. Gas Furnaces in Pennsylvania.
L & L Special Furnace is a manufacturer of industrial furnaces, electric furnaces, pit furnaces, gas fired furnaces, atmosphere furnaces, carburizing furnaces, retort furnaces and batch furnaces. We provide quality engineering and workmanship with excellent service. Let us be your source for furnaces. Gas Furnaces in Pennsylvania.
Industrial heat treating furnaces, kilns and ovens are manufactured here. Our small- to medium-size furnaces include gas fired furnaces, laboratory furnaces, box, dual chamber, top loading, bottom loading, continuous and car bottom furnaces. We make custom furnaces and have replacement parts. Gas Furnaces in Pennsylvania.
Olson Industries is a designer and manufacturer of special-application industrial furnaces, tempering furnaces, slot forged furnaces and other types. We also do vacuum furnace rebuilds. Spare parts and services, fabrication of steel and alloy parts plus existing furnace modernization are offered. Gas Furnaces in Pennsylvania.
SECO/WARWICK is a world-class manufacturer of heat treating furnaces, including aluminum furnace systems, vacuum furnaces, controlled-atmosphere brazing furnaces, aluminum solution heat treat furnace systems, melting furnace systems and thermal process furnace systems. For more information, call us or visit our website. Gas Furnaces in Pennsylvania.
Selas Heat Technology has been innovating high quality industrial burners, combustion systems & safety equipment for thermal processing applications since 1896. Our experienced engineers design Selas furnaces to be fuel efficient, dependable in the most extreme situations & cost-efficient for your thermal process. Industries served—glass, steel, chemical, food, textile, pulp/paper and many more. Gas Furnaces in Pennsylvania.
The Rose Corp combines highly skilled craftsmanship, technology & sizable facilities to produce high quality industrial furnaces. We are licensed by the Drever Company to upgrade & service as well as sell new furnaces, atmosphere generators, ammonia dissociators & spare parts to customers. The Rose Corp also provides box, tip-up & roller hearth furnaces to the steel & specialty metals industry. Gas Furnaces in Pennsylvania.
Trent designs and manufactures standard and custom industrial electric furnaces, laboratory furnaces, conveyor furnaces and ovens plus electrical heating elements, jackets, kettles and ovens. Our products are built to reach temperatures up to 2000°. Harold E. Trent started this business in 1927. Gas Furnaces in Pennsylvania.


Kaiser Foundation Health Plan, Inc. ("Kaiser") has agreed to pay $150,000 to settle claims by the California Attorney General (the "AG") that Kaiser's notification to California residents regarding a breach of their personal information was unreasonably delayed. In its suit, the AG alleged that Kaiser should have provided notice as soon as it determined that particular individuals' information had been or was "reasonably believed to have been" breached – even before Kaiser concluded its internal investigation. The case, California v. Kaiser Foundation Health Plan, Inc., is one of the first of its kind and will likely impact companies' data breach disclosure practices.
In the United States, disclosure of breaches of personal information (also referred to as "personally identifiable information" or "PII") is largely governed by the law of the state(s) where the affected individuals reside. Currently, 46 states, the District of Columbia, and several territories have enacted laws requiring companies to notify their residents of breaches involving personal information. Although the precise definition of "personal information" varies by state, it typically includes names combined with social security numbers, driver's license numbers, state ID card numbers, or financial information. Section 1798.82 of the California Civil Code ("the Notification Law") requires owners of computerized data to notify California residents of any breach that exposes their personal information "in the most expedient time possible and without unreasonable delay, consistent with the legitimate needs of law enforcement . . . or any measures necessary to determine the scope of the breach and restore the reasonable integrity of the data system." Under California unfair competition law, any "unlawful, unfair or fraudulent business act or practice" – including breach of the Notification Law – constitutes "unfair competition" and the AG may seek injunctive relief and/or civil penalties.
In its complaint, the AG alleged that Kaiser learned in September 2011 that an external hard drive containing the personal information of its employees had been sold at a thrift shop to a person unaffiliated with Kaiser. By December 2011, Kaiser secured custody of the hard drive and began a forensic examination of the drive. The initial analysis, which was completed in December, allegedly revealed that the drive contained social security numbers and related personal information of at least 30,000 employees and some of their family members; but the forensic exam continued through at least February 2012. Kaiser notified the affected California residents in mid-March – about six months after it first learned of the breach and four months after it began its forensic analysis. According to the AG, this constituted "unreasonable delay." Interestingly, although the forensic examination of the drive continued through February 2012, the AG alleged that Kaiser had sufficient information to notify at least some of the impacted individuals in December 2011 and violated the Notification Law by failing to do so.
Kaiser has agreed to settle the AG's claims without admitting liability. In a stipulated judgment filed for the court's approval, Kaiser agreed to pay $30,000 in civil penalties and $120,000 in attorney's fees and costs of investigation and prosecution. Kaiser also agreed to an injunction against further violations of the Notification Law with respect to personal information of current or former employees. The injunction specifically requires Kaiser to provide notification of any future breaches of employee personal information on a "rolling basis" where "feasible and appropriate," meaning Kaiser must provide notice "as soon as reasonably possible after identifying a portion of the total individuals affected by a breach, even if Kaiser's investigation of the breach is ongoing" and must "continue to notify individuals as soon as they are identified, throughout and until completion of Kaiser's investigation of the breach." Within 120 days of the judgment, Kaiser must also undertake additional employment training; review its policies regarding encryption of emails containing employee personal information and devise a plan for updating those policies as needed; conduct an audit regarding employee access to employee personal information; and provide a report to the AG's office regarding its audit.
The AG's suit against Kaiser and the resulting settlement may have far-reaching implications for companies responding to a data breach. Relying upon the apparent flexibility of the phrase "without unreasonable delay" and the allowance for delayed notice when "necessary to determine the scope of the breach" – both of which are typically included in state disclosure laws – companies have often delayed notifications until they conclude their investigations. This has numerous advantages, including allowing the company time to determine what specific information was breached, reducing the number of "false positives" (notifications to unaffected individuals), minimizing the number of inadvertently inaccurate communications regarding the breach, and allowing the company a measure of control over the public relations aspect of disclosure. Given the AG's lawsuit and the resulting settlement, however, this measured approach may no longer be an option – at least where California residents' information may have been involved in a breach. The case may also inspire other attorneys general to narrowly interpret their own states' "unreasonable delay" clauses.
Given the rapidly evolving state of cybersecurity law and the massive liability that breached companies can face, we strongly recommend that companies engage legal counsel immediately upon receiving notice that a breach may have occurred. Haynes and Boone, LLP provides investigation, remediation, and disclosure services to companies that suspect a breach and represents them in resulting regulatory actions, litigation, and other disputes. For additional information, please contact one of the attorneys listed below.


text:
Exclusive World Premiere: Portugal. The Man's "Sleep Forever"
Posted by Grayson Currin on June 6th
Portugal. The Man frontman John Gourley doesn't remember much about last night: All he knows for certain is that his art-rock band from Wasila, Alaska, had fun watching the NBA Finals in a bar in Portland, Maine. He thought everything was fine until everyone woke up this morning, bruised and battered covered in blood. Apparently, there was a fist fight, but Gourley doesn't know anything about it. Still, as tough as that might have been, it pales in comparison to the role Gourley plays in Sleep Forever, the new two-song music video from the band's forthcoming Atlantic Records debut, In The Mountain In the Cloud. Here, Gourley stars as a dogsled musher racing through the Alaskan wilderness; things get even more interesting when his dogs disappear.
We talked to Gourley about growing up in Alaska and In The Mountain In the Cloud.
Tell me about the genesis of the idea for this video? How did you decide you'd be a dog musher who died doing the job?
Along the lines of everything we do, we're constantly just throwing out ideas, and then every now and then, somebody grabs on to one and says, "You have to do this." We scramble and try to actually make it happen. Mike and I had been talking about doing this video where I would get lost. The dogsled thing was an easy setup for the video. My parents are dogsled mushers. My dad ran the Iditarod five or six times. He was one of the judges on the Iditarod. Mom and Dad ran together and also did the Yukon Quest. I was raised around these dogs and dog mushing. That was the easy part. Somewhere in talking about this, we wanted to have this crazy trapper involved in the video, because Alaska really is that place. I remember riding my bike or four-wheeler or walking out into the woods, and you'll find these undeveloped subdivisions with a house built out of palettes and green house material, randomly in a lot. You don't know if they own the lot or if they're just there. There are a lot of places like that of people just out in the woods. It's one of my favorite parts of Alaska, and also one of the most terrifying when you're a little kid–walking through the woods and stumbling upon it. We wanted to write that story and not actually have this hunter come after me but obviously fall and shoot myself.
Have you ever encountered a dangerous Alaskan situation like that?
There are all these crazy pits or air pockets that happen beneath the snow when the snow gets very deep. We were talking about me running through this field and falling in this pocket and killing myself. Growing up, we lived outside of Denali National Park; at one point, I was walking through these snowdrifts, and I stepped on top of a fairly tall spruce tree and fell down between all the branches. I ended up in this air pocket, deep in snow. I couldn't even stick my hands out of it. All those different experiences growing up brought around a lot of the videos. A lot of the stuff was actually loaned to us from a trapper and a hunter–one of our family friends. was going back to all my childhood experiences.
I was really glad we got to bring Mike Ragen up to do it. He has an amazing eye. We talked about doing these really big shots. That's what Alaska is: You look around, and it's mountains as far as you can see, mountains of trees. Everything is bigger than you. You're just a speck out there. All the shots were behind the house I grew up in and the house I currently live in. It was really easy for us to do because we had the space to do it. My dad helped out with the dogs.
How did you get out of that pit?
I just tunneled out. I was a little kid, and little kids do not stress those situations. As an adult, I'd probably freak out for a second; as a kid, it was awesome. I just fell into a room. There was naked earth beneath the tree, and I was in this spot that I wouldn't see for four months before everything thawed. We'll probably use a more in-depth view of something like that at some point.
The band's from Alaska, but for a lot of reasons, most Americans will likely never visit the state. Are these videos a chance to show your fans where you're from?
Definitely. There are all these shows on TV right now showing Alaska life. Some of them are pretty on-point. Things like Alaska State Troopers and Flying Wild Alaska, that's really Alaska. I think it's great for people to see that in a more artistic way, which is again why we brought up Mike to do it. He has a great talent for taking it all in and showing what it is to be there. That's literally my backyard; that's what it looks like. It was so much fun to be out there.
The most fucked-up thing about it was the fact that, before going out there, we'd decided the character wasn't going to wear a hat in this video. I go with it because I'm an Alaskan, and that's just what we do. We go out, and it was between 25 below and 50 below the last day we shot. It's 50 below zero, and there are some serious moments of desperation in my face. At one point, it's the least flattering shot of the whole video–just ice in my hair, ice on my eyelashes.
I actually stopped going out on dogsled rides with my dad. This one amazing day, we were in Denali out on the tundra. There was a herd of caribou out there. But we were out there for so long and my hat kept going back, so I frosted my ears. It was so frosted that I couldn't feel them, and in not feeling them, I tried to warm them up. I bent them and actually bent the cartilage. My ears were frozen all crooked. It was the worst feeling. I had these huge blisters and really swollen ears. I have a lot of respect for people who did things like my dad did–going out and running the Iditarod. People lose toes on the Iditarod. It gets black and frozen. There's just a more intense and real side to Alaska that we want to show a bit of in the video, and it was at my expense with the ice and the wind.
Is this video based on family lore? Is there a story of someone dying this way that this is based on?
It's something I've always been terrified of. There are stories of dogs getting stolen or getting killed. Dogs just get off the line and take off, and you get stuck. It happened to my dad back home. Sometimes the dogs will take a turn funny and send you into a tree, bust up the sled and take off. My dad's dogs will go back home, but a lot of times, you find that, if teams get loose, they'll get tangled up and fight or run into a moose. They get trampled. There are a lot of things that can happen out there, but the dogs do love it. It's what they live for. It's amazing to watch them communicate and how they handle things. But things definitely do happen up there.
But me killing myself… Well, a lot of the time, we do things just because we want to see how they would look. It just fit into the story really well. He doesn't actually get murdered. Once you're out there, you're running in every direction. You get stuck in whiteout situations, and people do die that way.
Why did you decide to use these songs–"Sleep Forever" and "Got It All (This Can't Be Living Now)"–to score the video?
We used to listen to a lot of Beatles and Bowie and oldies radio stuff. When we sat down to record this album, we wanted to bring in a lot of those reference points. I wanted to write a song that was more like the record we recorded three years ago, Censored Colors. There are a few callbacks lyrically, and that whole song, "Sleep Forever," was about family and growing up in Alaska. With that song referencing so much of that, it fit really well. It works really well with the landscapes and the big shots. It was a background to everything, and we needed that lift toward the end with "Got It All." That was more about lifting it back out and saying that we really do have it all out there.
You mentioned the television shows that have become representations of Alaska for people outside of the state. Being from Wasila, how do you view Sarah Palin's show?
It is what it is. It's a show. It's entertaining. My parents will watch it and think it's totally funny. As far as Alaska goes, I don't know. A lot of Alaskans are conservative no matter what. I'm not a true Alaskan. I grew up there, lived my whole life there, went to school with two other kids in my grade and the whole school in one two-room schoolhouse. That's not even real Alaska. That's just our family being there and living. I mean, people do that in Montana. Alaskan cities are still cities, and people live within those cities. I live in a different circle than the Palins, so I can't really relate. But it is totally entertaining, and that's what it's all about, right?

redpajama_set_name: RedPajamaCommonCrawl