\documentclass[a4paper,11pt]{article}

\usepackage{xspace}
\def\pkcs11{PKCS$\;$\#11\xspace}
\def\srp11{SRP$\;$\#11\xspace}
\def\c_#1 {\textsf{C\_#1()}\xspace}
\def\CKM_#1 {\textsf{CKM\_#1}\xspace}
\def\CKA_#1 {\textsf{CKA\_#1}\xspace}
\def\CKO_#1 {\textsf{CKO\_#1}\xspace}
\def\CKK_#1 {\textsf{CKK\_#1}\xspace}
\def\CK_#1 {\textsf{CK\_#1}\xspace}

%TODO% Contextual spacing is off
\def\tol#1{\longleftarrow\strut{}#1\strut\phantom{\longrightarrow}}
\def\tor#1{\phantom{\longleftarrow\strut}#1\strut\longrightarrow}

\parindent0pt
\parskip0.5\baselineskip

\begin{document}

\title{\srp11:\break Secure Remote Passwords behind \pkcs11}
\author{Rick van Rein\\OpenFortress}
\maketitle

\begin{abstract}
\noindent\em Secure Remote Passwords provide a zero-knowledge proof system for password-protected service access; furthermore, the protocol establishes a session key with forward secrecy properties.  These properties make it a desirable alternative to many other password schemes; its integration as a TLS cipher suite also makes it practically usable.
In this paper, we find what is required to use SRP with a randomly generated password that is protected by a \pkcs11 token.
\end{abstract}

\section{Introduction}

The SRP formalism is related to Diffie-Hellman, but it is not the same.  This means that implementation on a \pkcs11 token, with its stringent assumptions on the use of DH and the accompanying protection of secrets, is not trivial.  In fact, as will be shown here, we need to modify the client side of the protocol to be able to use SRP.  Since only the client-side changes and the cryptographic properties of the protocol are not impacted, this is a reasonable choice to consider.

\textbf{Formalism of SRP.}
The following exchange is defined for SRP.  Client and service are assumed to agree on DH parameters,  a generator $g$ and a hash function $H$.  All equalities in this paper are modulo the DH modulus.  The password is fixated by the client as $P$, which may be shared among many services without loss of security.  For each service, the client generates a random salt $s$ and passes it with a verifier $v$ to the service while setting up an account $C$.  So, the service stores $C\mapsto\langle s,v\rangle$ and treats $v$ as a secret, because it might elicit password cracking attempts.  The client stores $C$, which it sends to the service to get back the salt $s$ that it setup in the past.
%
\begin{eqnarray*}
\textbf{Client}&\textbf{Protocol}&\textbf{Service}\\
x=H(s,P)&&\\
v=g^x&&\\
&\tor{C,s,v}&\textrm{store $C\mapsto\langle s,v\rangle$}
\end{eqnarray*}

During authentication, the client picks random value $a$ and the service picks random values $u$ and $b$.  We assume the entropy of each of these three values to match the size of the to-be-derived session key.  The authentication protocol is conducted as follows:
%
\begin{eqnarray*}
\textbf{Client}&\textbf{Protocol}&\textbf{Service}\\
&\tor{C}&\textrm{lookup $\langle s,v\rangle$}\\
&\tol{s}&\\
x=H(s,P)&&\\
A=g^a&&\\
& \tor{A}&\\
k=H(N,g)&&k=H(N,g)\\
&&B=k\cdot v+g^b\\
&\tol{B}&\\
u=H(A,B)&&u=H(A,B)\\
S=(B-k\cdot g^x)^{a+ux} && S=(A\cdot v^u)b\\
K=H(S)&&K=H(S)\\
% M_1=H(A,B,K)&&\\
M_1=H(H(N)\oplus H(g),H(C),s,A,B,K)&&\\
&\tor{M_1}&\textrm{verify $M_1$}\\
&&M_2=H(A,M_1,K)\\
\textrm{verify $M_2$}&\tol{M_2}&
\end{eqnarray*}

\textbf{Rules of the game.}  We define the following constraints to the work laid out in this paper:
\begin{itemize}
\item The purpose of using \pkcs11 is to protect credentials from extraction, so that the SRP functions of the client cannot be implemented without the \pkcs11 token holding the password.
\item The random value $a$ is not protected by \pkcs11 because it only impacts the session key, and this value is also known to the service.
\item Intermediate values will be analysed; they are considered `public', that is need no \pkcs11 protection, when they can be derived on the service-side of the protocol.  Note however, that a passive observer sees less.
\item We only define client-side computations with \pkcs11, because the the service side does not handle any secrets, thanks to the zero-proof nature of the protocol.
\item We follow the assumption of SRP that the verifier is kept a secret by the service side; this is chiefly in the interest of the service, the client could employ SRP salt pinning to enforce it.  Salt pinning falls outside the scope of this paper.
\end{itemize}

\section{First Naive Implementation}

To demonstrate the problems that arise when implementing unchanged SRP on a \pkcs11 interface, we start off by making a sound technical implementation, and point out where this fails to satisfy the desired password protection for which \pkcs11 is being considered.

\textbf{Password establishment.}
A new password is generated with the DH mechanism in \c_GenerateKeyPair, in such a way that it must remain on the token.   This will be the password $P$ for the formalism.  Since the client performing this computation is also the party to generate salt and verifier, and to authenticate on later returning, there should be no conflict of interest to support key export.  Only for reasons of backup might wrapped export be permissible.

\textbf{Credentials generation.}
To derive service access credentials from the password, first generate a random salt $s$.  The value is public, and may be generated on or off the \pkcs11 token.  Then, the token's \c_DigestXXX functions must be used to compute the hash value $x=H(s,P)$ on the token; the password can be incorporated with \c_DigestKey pointing at $P$.

Now run \c_DeriveKey with $g$ as the base value and point to $x$ as the private key or exponent.  The outcome is $v=g^x$ which is supplied in a pair $\langle s,v\rangle$ to the service, together with a username.

\textbf{Authentication.}
The client starts off as basic DH with \c_GenerateKeyPair.  The private key will be known as $a$ and the public key is $A$.  Send $A$ over to the service.

The service generates $B=v+g^b$ for a local random secret $b$ and sends $B$ and $u$ to the client, where $u$ is another random scrambling parameter that is publicly shown.

The client now computes $B-g^x = B-v$, which is entirely based on public values.  The result equals $g^b$, which can be combined with session key $a$ in \c_DeriveKey to find $g^{ab}$, a normal DH result.

Then, $B^u$ is computed from public values, and used as a base key in \c_DeriveKey, with DH private key $x$.  This yields $B^{ux}=g^{bux}$, a value that can also be calculated separately on the service, as $v^{bu}=g^{xbu}$.

The values $g^{ab}$ and $g^{bux}$ are now multiplied outside of \pkcs11 to find shared secret $S$, which is of course also derived on the service.  Likewise, the session key $K=H(S)$ is also available to the service and not considered a secret that would benefit from \pkcs11 protection.

\textbf{Problem Analysis.}
The value of this implementation is that it never needs to extract the password $P$, so \pkcs11 can be exploited as a barrier to the secret.  However, this implementation calculates $x$ from a \c_DigestFinal invocation, which means it is delivered into a byte array that is extracted from \pkcs11.  The value $x$ is the only part of the protocol that contains $P$, so knowing $x$ is as useful as knowing $P$, at least for a service that uses the given salt value $s$.

In fact, in terms of the original AKA formalism of which SRP is an instance, the computation of $x$ falls outside the formalism as a mere parameter.  The use of $x$ in the SRP protocol may be considered a technical aspect, rather than a cryptographic necessity.  This means that we may consider modifications to the calculation of $x$ to make it better suited for \pkcs11 implementation.

\section{Client-side Variation on the Formalism}

The proposed variation to better adapt SRP to \pkcs11 is to use another one-way function than $H(s,P)$.  Within the SRP formalism, the operations for the DH mechanism offers an alternative, namely the \pkcs11 function \c_DigestKey which can be used as a modular-exponentiation operation, possibly incorporating secret exponentials.

As an alternative to $x$ in plain SRP, we define $x'=H(s) P$ to improve the integration.  This looks awful, because it is possible to derive $P$ from the values of $x'$ and $s$, but the damage is controlled by not actually depending on the value $x'$ in the implementation; instead, we use it to modify the formalism.  Note that the hash function has no cryptographic role in the AKA formalism, so we might even have specified $sP$ instead of $H(s) P$.  We choose to retain the hash because the salt may be used to carry additional values to pin down the service, and that could be computationally expensive or run into size constraints without the hash function.

During secret establishment, the client does not generate a random $P$ on the token, but instead constructs a DH key pair $\langle p,P\rangle$:
%
\begin{eqnarray*}
p &=& g^P
\end{eqnarray*}

Both $P$ and $p$ are concealed by \pkcs11, with no permission of extracting them.  Wrapped export might be supported to facilitate backup and recovery, but the values of $p$ and $P$ are assumed to not appear in plaintext outside of \pkcs11.

When setting up a service with a verifier and salt, the following process is used:
%
\begin{eqnarray*}
\textbf{Client}&\textbf{Protocol}&\textbf{Service}\\
% x' can be chosen freely within security constraints, and then v' is g^{x'}
x'=H(s) P&&\\
v'=p^{H(s)}&&\\
&\tor{C,s,v'}&\textrm{store $C\mapsto\langle s,v'\rangle$}
\end{eqnarray*}

The service cannot tell the difference, because the values $s$ is treated as an opaque string and because it is not of a different format; the value $v'$ is also not distinguishable for the service.

During authentication, the client picks random numbers $a$ and the service picks random values $u$ and $b$.  The authentication protocol is conducted as follows:
%
\begin{eqnarray*}
\textbf{Client}&\textbf{Protocol}&\textbf{Service}\\
&\tor{C}&\textrm{lookup $\langle s,v'\rangle$}\\
&\tol{s}&\\
v'=p^{H(s)}&&\\
A=g^a&&\\
&\tor{A}&\\
k=H(N,g)&&k=H(N,g)\\
&&B=k\cdot v'+g^b\\
&\tol{B}&\\
u=H(A,B)&&u=H(A,B)\\
S'=(B-k\cdot v')^a\cdot (((B-v')^u)^{H(s)})^P && S=(A\cdot {v'}^u)^b\\
K'=H(S')&&K=H(S)\\
% M_1'=H(A,B,K')&&\\
M_1=H(H(N)\oplus H(g),H(C),s,A,B,K)&&\\
&\tor{M_1'}&\textrm{verify $M_1'$}\\
&&M_2'=H(A,M_1',K)\\
\textrm{verify $M_2'$}&\tol{M_2'}&
\end{eqnarray*}

The calculation procedure for $S'$ by the client differs from the original calculation, but ought to yield the same output as the standard calculation of $S$ by the service under proper authentication conditions.  The same then holds for $K'$, $M_1'$ and $M_2'$.  We only use the accents to the symbols to distinguish their calculation and be able to prove equality.

Note that the value $x'$ is never seen in this calculation, nor can it be derived.  The value $P$ is used, but cannot be extracted from \pkcs11.

In terms of the original work on SRP, this is still an AKA formalism.  The change from $x=H(s,P)$ to $x'=H(s) P$ occurs in the periphery surrounding the AKA formalism definitions.  We will consider efficiency and security impacts in subsequent sections, but first turn to an implementation in terms of \pkcs11, using standard DH mechanisms.

\textbf{Proof of correctness.}
During authentication, the two sides need to find the same values for $S$ and $S'$, after which the values for $K'$, $M_1'$ and $M_2'$ follow without a change.  The thing to prove is that $S'$ in the client-side formalism yields the same result as $S$ in the service-side formalism, given that the service has received the value $v'$ instead of $v$.  The correctness is proven as follows:
\begin{eqnarray*}
S' &=& (B-k\cdot v')^a\cdot (((B-k\cdot v')^u)^{H(s)})^P\\
&=& (g^b)^a\cdot (g^b)^{uH(s)P}\\
&=& g^{ba}\cdot g^{buH(s)P}\\
&=& g^{ab}\cdot ((g^P)^{H(s)})^{ub}\\
&=& (g^a)^b\cdot (p^{H(s)})^{ub}\\
&=& A^b\cdot {v'}^{ub}\\
&=& (A\cdot v'^u)^b\\
&=& S
\end{eqnarray*}
This establishes that the unmodified SRP service algorithm, as well as the unmodified networking protocol, can work with the modified client that this formalism introduces.  The one thing to care for is that all clients adhere to the same new formalism, since they will need to base their work on $v'$ and not $v$.  Since the password pair $\langle p,P\rangle$ is concealed by \pkcs11, this constraint is already implied by the technology.

\textbf{Problem Analysis.}
The formalism presented here suffers from a cryptographic problem, namely that the value $p$ is assumed to be secret.  In normal Diffie-Hellman operations, only $P$ would be considered secret, and $p$ would be a public key.  Indeed, the value of $p$ could be recomputed from $g$ and $P$ by anyone with \pkcs11 access, and extracted.  The impact of this extraction would be that new values of $v'$ could be calculated without the help of \pkcs11; only authentication would continue to rely on live access to \pkcs11, but that is not the best possible result.  We therefore construct one further iteration.

Another problem that remains is the potential relationship between values of $v$.  Consider two values of $H(s)$, called $h_1$ and $h_2$.  Since these are random values, it may happen that $h_2$ is divisable by $h_1$, so when $v_1=p^{h_1}$ then $v_2=p^{h_2}=v_1^{h_2/h_1}$.  This problem is mitigated in plain SRP through the use of the hash function, and the next iteration must also resolve it through better scattering of the verifiers.

\section{Maximally \pkcs11 Protected Formalism}

On top of the suitability for \pkcs11 in previous variation, the additional requirement is now to avoid that verifiers can be constructed from extractable values like $p$.  This is ensured by applying the secret key $P$ to the salt.

As an alternative to $x$ and $x'$, we therefore define $x''={H(s)}^P P$.  This introduces a multiplication with secret $P$, which will make it impossible to derive password-equivalent value $x''$ in the implementation.  It also raises the salt to the power $P$ to require the password before the verifier can be computed.  Under the assumption that services conceal the verifier, a new service cannot be setup with the same salt, and the dependency on $P$ implies that only the client with \pkcs11 access can thus create a new salt and verifier for a new service.

The secret key $P$ established as before, with token-generated random key $P$, protected from extraction.  But in this variation, the value $p$ does not have to be protected from extraction.
%
\begin{eqnarray*}
p &=& g^P
\end{eqnarray*}

When setting up a service with a verifier and salt, the following process is used:
%
\begin{eqnarray*}
\textbf{Client}&\textbf{Protocol}&\textbf{Service}\\
% x'' can be chosen freely within security constraints, and then v' is g^{x'}
x''={H(s)}^P P&&\\
v''=p^{{H(s)}^P}&&\\
&\tor{C,s,v''}&\textrm{store $C\mapsto\langle s,v''\rangle$}
\end{eqnarray*}

As before, the service cannot tell the difference, because the value $s$ is treated as an opaque string and because it is not of a different format; the value $v''$ is also not distinguishable for the service.

During authentication, the client picks random value $a$ and the service picks random values $u$ and $b$.  The authentication protocol is conducted as follows:
%
\begin{eqnarray*}
\textbf{Client}&\textbf{Protocol}&\textbf{Service}\\
&\tor{C}&\textrm{lookup $\langle s,v''\rangle$}\\
&\tol{s}&\\
v''=p^{{H(s)}^P}&&\\
A=g^a&&\\
&\tor{A}&\\
k=H(N,g)&&k=H(N,g)\\
&&B=k\cdot v''+g^b\\
&\tol{B}&\\
u=H(A,B)&&u=H(A,B)\\
S''=(B-k\cdot v'')^a\cdot (((B-k\cdot v'')^u)^{{H(s)}^P})^P && S=(A\cdot {v''}^u)^b\\
K''=H(S'')&&K=H(S)\\
% M_1''=H(A,B,K'')&&\\
M_1=H(H(N)\oplus H(g),H(C),s,A,B,K)&&\\
&\tor{M_1''}&\textrm{verify $M_1''$}\\
&&M_2''=H(A,M_1'',K)\\
\textrm{verify $M_2''$}&\tol{M_2''}&
\end{eqnarray*}

The calculation procedure for $S''$ by the client differs from the original calculation, but ought to yield the same output as the standard calculation of $S$ by the service under proper authentication conditions.  The same then holds for $K''$, $M_1''$ and $M_2''$.  We only use the accents to the symbols to distinguish their calculation and be able to prove equality.

Note that the value $x''$ is never seen in this calculation, nor can it be derived.  The value $P$ is used, but cannot be extracted from \pkcs11.

In terms of the original work on SRP, this is still an AKA formalism.  The change from $x=H(s,P)$ to $x''={H(s)}^P P$ occurs in the periphery surrounding the AKA formalism definitions.  We will consider efficiency and security impacts in subsequent sections, but first turn to an implementation in terms of \pkcs11, using standard DH mechanisms.

\textbf{Proof of correctness.}
During authentication, the two sides need to find the same values for $S$ and $S''$, after which the values for $K''$, $M_1''$ and $M_2''$ follow without a change.  The thing to prove is that $S''$ in the client-side formalism yields the same result as $S$ in the service-side formalism, given that the service has received the value $v''$ instead of $v$.  The correctness is proven as follows:
%
\begin{eqnarray*}
S'' &=& (B-k\cdot v'')^a\cdot (((B-k\cdot v'')^u)^{{H(s)}^P})^P\\
&=& (g^b)^a\cdot (g^b)^{u{{H(s)}^P P}}\\
&=& g^{ba}\cdot g^{bu{H(s)}^P P}\\
&=& g^{ab}\cdot ((g^P)^{{H(s)}^P})^{ub}\\
&=& (g^a)^b\cdot (p^{{H(s)}^P})^{ub}\\
&=& A^b\cdot {v''}^{ub}\\
&=& (A\cdot v''^u)^b\\
&=& S
\end{eqnarray*}
This establishes that the unmodified SRP service algorithm, as well as the unmodified networking protocol, can work with the modified client that this formalism introduces.  The one thing to care for is that all clients adhere to the same new formalism, since they will need to base their work on $v''$ and not $v$ or $v'$.  Since the password $P$ is concealed by \pkcs11, this constraint is already implied by the technology.

\section{Implementation as \srp11}

The following describes how to implement the last iteration of the SRP mechanism and demonstrates its integration with \pkcs11.  Where the distinction is useful, we will distinghuish `plain SRP' from this modified form, which we will refer to as \srp11.

\textbf{Password establishment.}
A new `password' is generated with the \CKM_DH\_PKCS\_KEY\_PAIR\_GEN mechanism in \c_GenerateKeyPair , leading to a randomly generated private key $P$ and a public key $p$.  Only for reasons of backup might wrapped export of $p$ be permissible, but $P$ can be handled with more relaxation.  The two are never used separately, but the public key may be used outside of \pkcs11 for reasons of efficiency.

The base value used is the generator $g$, to establish the relationship $p=g^P$.  Both the base value and the modulus are commonly used group parameters for the SRP scheme, with a few standardised in Appendix A of RFC 5054.  These must be supplied as parameters to \c_GenerateKeyPair .  For standard modular-exponentiation Diffie-Hellman key exchange, cryptoanalytic advances suggest the use of non-standard groups, to evade dangers caused by pre-computed lookup tables.

\textbf{Private modular exponentiation.}
The private key can be used as an exponent in modular exponentiation through \c_DeriveKey with the \CKM_DH\_PKCS\_DERIVE method.  The outcome of this operation can be stored in a \CKO_SECRET\_KEY of type \CKK_GENERIC\_SECRET with \CKA_VALUE\_LEN set to the number of bytes in the modulus.  The template used must set \CKA_EXTRACTABLE to \CK_TRUE , so the outcome can be retrieved from the session; the outcome is stored as a session key and after extraction this key should be deleted with \c_DestroyObject if the session persists.  Programmers must be aware that implementations can remote leading zero bytes, and thus shorten the exported key.

\textbf{Public key regeneration.}
It is possible to regenerate the public key $p$ as $g^P$ because the private key is annotated with non-sensitive \CKA_PRIME holding the modulus and \CKA_BASE holding $g$.  The regenerated public key could be a session key that is not stored on the token even if the private key is.  This means that it is possible to compute the public key from scratch, had it been deleted, and implement caching schemes and so on for it.  This method can be used to save \pkcs11 storage capacity, or to avoid having to keep track of both keys.  It is costly however; it takes an extra modular exponentiation operation.  Another possibility is to export the public key value and store it off-token.

\textbf{Credentials generation.}
When fresh Diffie-Hellman group parameters are desired, these can be generated first.  To derive service access credentials from the password, generate a random salt $s$ of the same size as the outcome of $H()$.  The value of $s$ is public, and may be generated on or off the \pkcs11 token, although the entropy of \c_GenerateRandom is likely to be of higher quality than more or less deterministic source from an operating system.  Then, a hash function (not necessarily using the token's \c_DigestXXX functions) must be used to compute the hash value $x=H(s)$; the outcome can be used to calculate $p^{H(s)}$ off-token.  The result of that operation is input to private modular exponentiation, which requires access to the token, to generate the outcome $v''$.  This outcome is supplied in a pair $\langle s,v\rangle$ to the service, together with the client's username $C$ that serves as a lookup key for the pair.

\textbf{Authentication.}
The client starts off generating random bytes, at least the size of the hash $H()$,
and calls it $a$.  Random bytes are best generated with \c_GenerateRandom , because
the API potentially speaks to cryptographic hardware, making it
yield at least as good random material as an operating system can.
The client then uses private modular exponentiation to map $a$ to
$A=g^a$, which is transmitted to the service.

The service computes $k=H(N,g)$ and generates $B=k\cdot v''+g^b$ for a local random
secret $b$ and sends $B$ to the client.  Note that the computation of $B$ is
completely done in modulo arithmetic.  We are assuming SRP~6a, which does not
generate a random value $u$ on the server and sends it to the client, but instead
both compute $u=H(A,B)$.  Leading zero bytes should not be trimmed, to make $A$ and $B$
always have the same byte count as (the shortest representation of) the modulus.

Through the values of $p$ and $P$, the client can now reconstruct $v''$, which requires the non-extractable secret $P$; moreover, the outcome cannot be reversed to find the private value $P$ due to the properties of the discrete logarithm problem.  The value $v''$ is also known to the service, so it may be exported from the \pkcs11 interface.  The client can compute $k=H(N,g)$ and now uses $v''$ find $B-k\cdot v''$ with modular arithmetic, which is entirely based on values that the service also sees.  The outcome equals $g^b$, which can be combined with session key $a$ in \c_DeriveKey to find $g^{ab}$, a normal DH result.

The remainder of the modular computation of $S''$ consists of using the value $B-k\cdot v''$ in off-token multiplication and modular exponentiation, all based on the public values $B-k\cdot v''$, $u$, $H(s)$ and the locally generated random value $a$, all of which are safe to reveal outside of \pkcs11, and there will be two modular exponentiations with secret key $P$ as the exponent, to be conducted on the token behind the protective \pkcs11 API.  It is this last point where presence of the token is a strict requirement to derive the proper values.

Note that the value $S''$ is also available on the service, so we do not consider it a secret to be concealed behind \pkcs11.  [\textbf{TODO:} How about the $\ldots^P$ and ${\ldots^P}^P$ values, are they `public' too?]  Likewise, the session key $K=H(S)$ is also available to the service and not considered secret.

Note that the value of $x''$ is absent from the calculations.  Instead, the secret key $P$ is used.  In a normal calculation the dependency on a secret key might be a liability, but when using \pkcs11 this is not as problematic because of its ability to encapsulate private keys.  The value of $x''$ cannot be derived either, since the protected storage of the password values make it impossible to find the outcome of $H(s)p$ because that is not part of the DH mechanism.

\paragraph{Keys and Verifiers.}
The computation of $K''=H(S'')$ is a trivial hashing operation that does not require padding of $S''$, so we don't do it in \srp11.  The computation of $M_1''$ and $M_2''$ are however sensitive to the problems of concatenation of variable-sized fields; bytes from one might be cut off and attached to another while retaining the same hash.  Under SRP, this has not been solved with unambiguous separators, nor by length annotation, so the number of bytes of $A$ and $B$ in the hashing computations must be fixed to the same number of bytes as (the shortest representation of) the modulus.  Sizes of $K''$ and $M_1''$ are fixed by the hash algorithm $H()$, so they need no special treatment.  Finally, the value $H(N)\oplus H(g)$ does not have this problem and so there is no need to pad $g$; both $N$ and $g$ can have the shortest possible byte sizes.  It is common for SRP to apply no padding in the computation of $k=H(N,g)$ either.

\section{Performance Considerations}

The use of the more protective private-key encapsulation of \pkcs11 comes at a price of reduced efficiency.  Note that this plays particularly at the client side, which means that it is subject to user selection of technology, and more importantly, meaning that scaling problems are not likely to be a problem --- as we are talking of an alternative to manual password entry.

Still, a performance indication is useful.  The overruling consideration in this sense is how many modular-exponential operations take place.  More accurately put, the number of bits that may hold a value in the exponent of these operations.  We are going to base our performance considerations on the assumption that the random values $s$, $a$, $b$, $u$ all match the size of the outcome of the hash algorithm $H$.  So, we can count the number of times such bits occur in the exponent of a calculation.

The chief concern is the authentication process.  In the original process we find client-side exponents $a$, $x$ and $a+ux$, sized like 1, 1 and 2 hashes, so plain SRP weighs like 4 modular exponentiations with the size of the outcome of $H$.  In \srp11, the client-side exponents during authentication are $H(s)$, $a$, $a$, $u$, $P$, $P$ and $H(s)$, which weighs like 7 modular exponentiations.

Clearly, the inability of computing $a+ux$ before the exponention forces in extra computations in return for the added security of not handling $x$ in \srp11.  The computational comlexity of \srp11 is about 75\% higher than for plain SRP.  This factor is probably irrelevant in comparison to the (possible) move of the calculation to a piece of hardware.  Hardware tends to be either much slower (USB token) or much faster (HSM, crypto co-processor) at performing modular exponentiation than a CPU.

We performed measurements that compared an SRP implementation to \srp11, the latter communicating with a software-based HSM.  Both procedures included a client and a server running in the same process on the same machine, so as to eliminate network delays.  We used the standard group with a 4095 bits modulus.  The results indicate that \srp11 takes ten to twelve times as much computation time as SRP.  This has not been unravelled to separate the \pkcs11 overhead from the computations themselves, because there will always be \pkcs11 overhead when \srp11 is being used.  The total computation time of one \srp11 verification run on a 2.2 GHz amd64 machine took about 175~ms.

\section{Security Considerations}

The values that are available as intermediate results in \srp11 are all `public', in the sense that the service can also find them based on what it knows.  Most computations are based on a generator raised to a (secret or public) exponent, which is considered irreversable on grounds of the infeasability of the discrete logarithm problem.  [\textbf{TODO:} The values $\ldots^P$ and ${\ldots^P}^P$ might be non-`public'; to be determined whether they could do harm.]

The value $v''$ is known to the service, and therefore its derivation as $p^{H(s)P}$ during authentication does not reveal information that should be protected by \pkcs11.  The value $B-k\cdot v''$ is `public', and so is $a$, so computing $(B-k\cdot v'')^a$ presents no problems.  The same holds for $(B-k\cdot v'')^u$ and the next step, $((B-k\cdot v'')^u)^{H(s)}$.  The latter value is then twice raised to the value $P$ that is protected behind \pkcs11, but an attacker would need to crack discrete logarithms to reverse this to find $P$.  The outcome of this last operation is equal to the service-side value $S$ multiplied by the inverse of the public-value based $(B-k\cdot v'')^a$, so having the value once more reveals no new information.  The remainder computers $K$, $M_1$ and $M_2$ on both ends, so there is no question about their revelation of new information that ought to be protected \pkcs11.

It is worth noting that a client might turn rogue when it is cracked; in such cases, it might gain the rights to authenticate, but it should not gain access to the passwords through which it can mount future attacks on other locations.  This makes the common assumption that the credential protection of \pkcs11 is not cracked; an assumption that can be influenced by a suitable choice of \pkcs11 implementation.  Plain SRP and \srp11 are not different in this respect, and in fact it is common to all DH mechanism.  Another point common to all three variations is that thrashing of the random values $a$ and $b$ suffices to thwart future attackers from recovering session keys of traffic preceding the crack on the client (forward secrecy).

The value $p=g^P$ is retained as a `cache' value.  Rogue access to \pkcs11 might consider replacing this value with a more suitable value, to influence future computations based on it.  This is not likely to lead to anything useful however; first, it would be noticed when accessing a non-rogue service; second, the value $P$ is still used in computations; and third, the discrete logarithm problem makes it notoriously difficult to derive a value of $p$ that would lead to a desired outcome.  A much better attack would be to replace both $p$ and $P$ which is comparable to replacing a password; this however, would not leak any information about the prior value of $P$ and would invalidate access to services setup with it.

Modular exponentiation cannot be reversed, as a result of the discrete logarithm problem.  The start of the computation is $B-k\cdot v''$, which equals $g^b$ and that uses an unknown value $b$.  Raising this to the powers $u$, $H(s)$, $P$ and $P$ in any order should stir the value even further, but in lieu of the value $b$ on the client and due to the discrete logarithm problem it is unlikely that an attack could be mounted from this angle.  \textbf{Open Question:} Can we prove that?

In conclusion, the maximum protection that \pkcs11 can deliver has been achieved with \srp11, under the assumption that what the service knows is sufficiently public.  That angle however, is subject of potential crisitism.  It could be argued that the service is in a special position.  For one, it generates random string $b$ internally and only publishes the corresponding $B$; but that alone would not make much difference, an active MITM attack could produce similar values. The vital distinction is that the service knows $v'$, which is assumed to have been relayed to it in a covert manner, and so it is a shared secret between client and service --- one that would not be available to anyone on the channel between client and service.

Unfortunately, it is not possible to redesign \srp11 to treat $v''$ as a secret value.  This can be seen directly in the computations; the construction $(B-k\cdot v'')^e$, regardless of the exponent $e$ cannot be computed with DH values, because subtraction is not foreseen in this mechanism.  This is where \pkcs11 reveals that it was not designed with plain SRP or \srp11 in mind.  And since exponentiation does not distribute through subtraction, neither modular or otherwise, we cannot construct any such mechanism cleverly.

Note that the visibility of $v''$ is less than perfect, but not truly problematic in itself.  The sole reason for treating all data available to the service as public is to avoid putting too much faith in what \pkcs11 can do.  Apparantly, this is its limitation.  Note that this is also caused by something else --- the client is the party that originally generated $v''$ and would be able to do that again.

In conclusion, \srp11 actually improves the security of SRP by taking the passwords out of sight and placing them behind \pkcs11; in addition, the password-equivalent value $x$ is not available to the \srp11 computations due to \pkcs11 shielding.  The one thing that is not possible, is to also conceal the computation of verifier values $v''$ from the client, but it has been demonstrated that this would have introduced a false sense of security anyway.  In conclusion, \srp11 establishes precisely the maximum achievable and the maximum desirable protection of SRP credentials.

\section{Conclusions}

This article introduces \srp11, a variation on SRP that uses \pkcs11 to protects the password and password-equivalent values that are computed on the client side.  It has been shown that a direct implementation of plain SRP with \pkcs11 does protect the original password, but not the password-equivalent value $x$, which means it is useless.  In contrast, the \srp11 variation achieves precisely the maximum achievable and maximum desirable that \pkcs11 could offer.

It has been shown that the modified generation of salt and verifier combined with the modified client-side authentication computations compute values equivalent to those of plain SRP, and that the service or protocol require no changes.  In other words, only the client needs to modify its computations if it intends to use \pkcs11.

In terms of efficiency, the \srp11 mechanism adds a factor ten to twelve to the running time in comparison to plain SRP, but the execution times are still quite acceptable.  When \pkcs11 is implemented on hardware, then choice is likely to have a stronger impact on the speed of the computations --- they would take longer when a plain USB token is used, and would go down when cryptographic acceleration is built into the hardware.

\end{document}


\section{Algorithm}

In this section we describe the components of our algorithm and the
flow of data between these components.  The algorithm predicts the
syntactic category of a word in a given context based on its random
substitutes sampled from a statistical language model.  First, we
construct a pairwise co-occurrence representation of words and their
substitutes.  Next, we map each word and each substitute in the
co-occurrence data to real vectors (embeddings) on an $n$-dimensional
sphere using the S-CODE algorithm \cite{maron2010sphere}.  S-CODE
places the vectors for words that frequently co-occur with the same
substitutes (and substitutes that co-occur with the same words) close
to each other on the sphere.  We then apply k-means clustering to
group word and substitute embeddings and we induce word categories
from the resulting groups.  In Section~\ref{sec:cooc} we detail the
representation of words and their substitutes as co-occurrence data,
in Section~\ref{sec:embedding} we describe the embedding algorithm,
and finally in Section~\ref{sec:clustering} we describe the different
ways in which words and substitutes can be clustered to give us
categorizations of word types or tokens.

\subsection{Context Representation}
\label{sec:cooc}
% How we represent the context?
% How we relate the word and the context?

We represent the context of a word with random substitutes that are
likely to occupy the same position as the word.  We sample random
substitutes (with replacement) from a substitute word distribution for
the context calculated based on an n-gram language model.  The sample
space of the substitute word distribution is the vocabulary of the
language model.
%% \footnote{Sampled substitutes might include the unknown
%%   word tag \unk\ representing words outside the fixed size
%%   vocabulary of the language model.  For example proper nouns
%%   typically have \unk\ as a substitute.}
In effect, we are using
substitute word distributions and the sampled random substitutes as
{\em contextual features} that represent properties of a word's
position.  Table~\ref{tab:subdist} shows the substitute word
distributions for some positions in an example sentence.

\begin{table}[h]
\caption{The substitute word distributions (with probabilities in
  parentheses) for some of the positions in the example sentence
  \textit{``Pierre Vinken, 61 years old, will join the board as a
    nonexecutive director Nov.~29.''} based on a 4-gram language
  model.}
\label{tab:subdist}
\begin{tabular}{|ll|} \hline
\textbf{will:} & \textit{will} (0.9985), \textit{would} (0.0007), \textit{to} (0.0006), \textit{also} (0.0001), $\ldots$ \\
\textbf{join:} & \textit{join} (0.6528), \textit{leave} (0.2140), \textit{oversee} (0.0559), \textit{head} (0.0262), \textit{rejoin} (0.0074), $\ldots$ \\
\textbf{the:}  &\textit{its} (0.9011), \textit{the} (0.0981), \textit{a} (0.0006), $\ldots$ \\
\textbf{board:} & \textit{board} (0.4288), \textit{company} (0.2584), \textit{firm} (0.2024), \textit{bank} (0.0731), \textit{strike} (0.0030), $\ldots$ \\
\hline
\end{tabular}
\end{table}

To capture the relation between each word and its context we construct
a co-occurrence representation by pairing the words with randomly
sampled substitutes.  Table~\ref{tab:samples} shows random substitutes
of each word and their pairwise co-occurrence representation input to
S-CODE for an example sentence.  It is possible (and beneficial) to
sample more than one substitute and generate multiple pairs for the
same word-context pair as seen in Table~\ref{tab:samples}.  A target
word might appear both as a word and a random substitute therefore to
clarify this ambiguity we prepend ``W:'' and ``S:'' to words and
substitutes, respectively, in the co-occurrence data.  The calculation
of substitute distributions and random substitute sampling are
detailed in Appendix~A.

\begin{table}[ht]
  \caption{The table on the left shows three possible substitutes
    sampled with replacement for each position in an example sentence
    based on a 4-gram language model.  The table on the right is the
    pairwise co-occurrence data fed to the S-CODE algorithm derived
    from these samples.  The prefixes ``W:'' and ``S:'' are used to
    distinguish target words and substitutes.  Sampled substitutes
    might include the unknown word tag ``\unk'' representing words
    outside the fixed size vocabulary of the language model.}
\begin{tabular}{|ll|} \hline
\textbf{Word} & \textbf{Random Substitutes}\\
\hline
Pierre & \textit{Mr.}  / \textit{Pierre} /  \textit{John}\\
Vinken & \textit{\unk} / \textit{Beregovoy} / \textit{Cardin}\\
, & \textit{,} / \textit{,} / \textit{,}\\
61 & \textit{48} / \textit{52} / \textit{41}\\
years & \textit{years} /  \textit{years} /  \textit{years}\\
old & \textit{old} /  \textit{old} /  \textit{old}\\
, & \textit{,} /  \textit{,} /  \textit{,}\\
will & \textit{will} /  \textit{will} /  \textit{will}\\
join & \textit{head} /  \textit{join} /  \textit{leave}\\
the  & \textit{its} /  \textit{its} /  \textit{the}\\
board & \textit{board} /  \textit{company} / \textit{firm}\\
as & \textit{as} / \textit{as} / \textit{as}\\
a & \textit{a} / \textit{a} / \textit{a}\\
nonexecutive & \textit{nonexecutive} / \textit{non-executive} / \textit{nonexecutive}\\
director & \textit{chairman} / \textit{chairman} / \textit{director}\\
Nov. & \textit{April} / \textit{May} / \textit{of}\\
29 & \textit{16} /  \textit{29} / \textit{9}\\
. & \textit{.}  / \textit{.} / \textit{.}\\
\hline
\end{tabular}
\quad
\begin{tabular}{|ll|}
\hline
\textbf{Word} & \textbf{Substitute}\\
\hline
W:Pierre & \textit{S:Mr.}\\
W:Pierre & \textit{S:Pierre}\\
W:Pierre & \textit{S:John}\\
W:Vinken & \textit{S:\unk}\\
W:Vinken & \textit{S:Beregovoy}\\
W:Vinken & \textit{S:Cardin}\\
$\hdots$&\\
W:join & \textit{S:head}\\
W:join & \textit{S:join}\\
W:join & \textit{S:leave}\\
W:the & \textit{S:its}\\
W:the & \textit{S:its}\\
W:the & \textit{S:the}\\
$\hdots$&\\
W:director & \textit{S:chairman}\\
W:director & \textit{S:chairman}\\
W:director & \textit{S:director}\\
$\hdots$&\\
\hline
\end{tabular}
\label{tab:samples}
\end{table}

The next section describes the S-CODE algorithm which takes the
pairwise co-occurrence data as its input and calculates the embeddings
of the words and their substitutes on an $n$-dimensional sphere.

\subsection{Co-occurrence Embedding}
\label{sec:embedding}
The S-CODE algorithm maps each unique word and substitute in the
co-occurrence data to a real vector (embedding) on an $n$-dimensional
sphere as detailed in Appendix~B.  The basic idea of the mapping is
that words and substitutes that are frequently observed as pairs in
the co-occurrence data will have close embeddings while pairs
not observed together will have embeddings that are far apart from each
other.

\begin{figure}[ht]
\centering
  \begin{minipage}[c]{0.38\textwidth}
    \begin{tabular}{|l|l|}
    \hline
    \textbf{Word} & \textbf{Substitute} \\
    \hline
    $\hdots$&$\hdots$\\
    W:director & S:chairman \\
    W:chief & S:chairman \\
    $\hdots$&$\hdots$\\
    W:Pierre & S:John \\
    W:Frank & S:John \\
    $\hdots$&$\hdots$\\
    \hline
  \end{tabular}
  \end{minipage}
  \begin{minipage}[c]{0.48\textwidth}
    \includegraphics[height=.6\textwidth]{scode-ex.png}
  \end{minipage}
  \caption{The figure on the right represents the final embeddings for the
    words and substitutes from the co-occurrence data on the left after
    S-CODE converges.  Dashed circles represent the possible groupings
    of the embeddings on the sphere.}
  \label{fig:scodeexample}
\end{figure}

The co-occurrence data in Figure~\ref{fig:scodeexample} consists of
pairs such as (\textit{W:director}, \textit{S:chairman}) and
(\textit{W:chief}, \textit{S:chairman}) therefore S-CODE forces the
embeddings of \textit{W:director} and \textit{W:chief} to be close to
the embedding of \textit{S:chairman}.  Similarly the embeddings of
\textit{W:Pierre} and \textit{W:Frank} will be close to the embedding
of \textit{S:John} because they are frequently co-occurring pairs.  As
a result the final embeddings of \textit{W:director} and
\textit{W:chief} will be close to each other due to the common
substitute \textit{S:chairman} and will be apart from
\textit{W:Pierre} and \textit{W:Frank} due to the lack of common
substitutes (similarly the embeddings of \textit{W:Pierre} and
\textit{W:Frank} will be close to each other due to \textit{S:John}).

The coordinates of the embeddings for each unique word and substitute
constitute the input to the clustering stage as described in the next
subsection.

% How we relate final embeddings and the input pairs?
%% S-CODE constructs embeddings on an $n$-dimensional sphere for each word
%% type and substitute.  Each pair in the co-occurrence data can be
%% represented in three different ways by using the output of S-CODE: (1)
%% word embedding (${\bf W}$) which represents the word type information,
%% (2) substitute embedding (${\bf C}$) which represents the context
%% information, and (3) concatenation of word and substitute embeddings
%% (${\bf W}\oplus{\bf C}$).  In the next section we apply k-means
%% clustering to these three representation and analyze the
%% characteristic of final clusters.

\subsection{Clustering}
\label{sec:clustering}
%% In Section~\ref{sec:cooc} we describe the transformation of an input
%% sentence to a co-occurrence data and we represent each target word
%% with the word--substitute pair(s).  In the previous section we
%% construct embeddings for each value observed in the co-occurrence data
%% using the S-CODE algorithm.

At this stage, each unique word in the text and each unique substitute
sampled to represent their contexts is mapped to a real vector
embedding on an $n$ dimensional sphere\footnote{In fact many words
  that appear in the text also appear as substitutes and thus get two
  embeddings.}.  We apply the instance weighted k-means clustering
algorithm to three different representations derived from these
embeddings, each with its own advantages and disadvantages:

\paragraph{Clustering word embeddings (${\bf W}$)} In the first setting,
we ignore substitute embeddings and apply clustering only to target
word embeddings.  Each target word {\em type} has a single embedding,
and gets assigned to a single cluster.  Thus clustering target words
based on this representation can only assign a single tag to each word
type and cannot represent multiple parts of speech for ambiguous
words (words that have more than one tag).

For example, the word {\em offer} is tagged as NN(399), VB(105) and
VBP(34) in its 538 PTB occurrences\footnote{NN, VB and VBP are three
  part-of-speech tags from the Penn Treebank corpus and they
  correspond to singular noun, verb in base form and
  non-$3^{rd}$person singular verb in present tense, respectively.}.
When all instances of {\em offer} are assigned to the same cluster,
the \mto\ upper bound of {\em offer} will be 399/538=.74 using the
most frequent tag NN.

Clustering word embeddings was previously explored in
\cite{yatbaz-sert-yuret:2012:EMNLP-CoNLL}, which achieved the best
results to date (80\% \mto) for English.
Sections~\ref{sec:clustering-w} and \ref{sec:feat} summarize these
experiments for completeness.  The surprising success of the
one-tag-per-word assumption in English part of speech induction is
partly due to the fact that 93.69\% of the word occurrences in the
human labeled PTB data are tagged with their most frequent part of
speech \cite{Toutanova:2003:FPT:1073445.1073478}.  However the
clustering performance on ambiguous words is bounded and the utility
of a part of speech induction model which cannot handle ambiguity is
questionable.

%offer tag distribution in WSJ VBP 34, VB 105, NN 399
\paragraph{Clustering substitute embeddings (${\bf S}$)}
In a second set of experiments, we ignore target word embeddings and
apply clustering only to substitute embeddings, associating each
substitute with a unique cluster.  We then categorize target word {\em
  tokens} based on what cluster the majority of their substitutes
belong.  It is important to note that in this setting we are ignoring
the identity and features of the target words and in effect clustering
word contexts (substitutes are determined by the context and are
conditionally independent of the target word).

For example, the target word {\it W:board} in Table~\ref{tab:samples}
will be represented with the embeddings of {\it S:board}, {\it
  S:company} and {\it S:firm} while another occurrence of the word
{\it W:board} in a different context might be represented with
embeddings of different substitutes such as {\it S:embark} or {\it
  S:enter}.  Each occurrence of the target word ``board'' is assigned
to the cluster in which the majority of its substitute embeddings are
present\footnote{Ties are broken randomly.}.  This approach generally
results in higher accuracy for highly ambiguous words like {\em offer}
where clustering substitute embeddings achieves .82 \mto\ compared
to the one-tag-per-word upper bound of .74.
Section~\ref{sec:clustering-s} presents the results of experiments
clustering substitute embeddings.

Unfortunately such highly ambiguous words do not constitute a
significant portion of the corpus and the overall accuracy suffers
(.64 compared to .80 \mto\ for word clustering).  We also observed
similar results in our preliminary experiments without S-CODE trying
to cluster contexts directly (using the Kullback-Leibler divergence
between their substitute distributions).  Many common words that occur
in similar contexts and that have similar substitutes, e.g. {\em his}
and {\em the}, belong to different parts of speech.  In addition,
words that are generally not substitutable like ``do'' and ``put'' are
placed in the same category by the PTB.  This suggests that the
identity and features of the target word are indispensable and that a
purely substitutability based linguistic definition is insufficient
for inducing parts of speech as tagged in the PTB.

\paragraph{Clustering the concatenation of word and substitute
embeddings (${\bf W\oplus S}$)} In a third set of experiments we
concatenate the $n$-dimensional embedding vector for each sampled
substitute with the $n$-dimensional embedding vector of its target
word and apply clustering to the resulting $2n$-dimensional vectors.
We then categorize target word {\em tokens} based on what cluster the
majority of their substitute-concatenated vectors belong.  For
instance, the target word ``Pierre'' in Table~\ref{tab:samples} will
be represented with three vectors that will be the concatenation of
the embedding of {\it W:Pierre} with the embeddings of {\it S:Mr.},
{\it S:Pierre} and {\it S:John}, separately.  Models that are based on
this representation do not employ the one-tag-per-word assumption,
they can cluster word tokens, and they can represent ambiguity.
Clusters that are constructed according to this representation tend to
assign fewer categories to each word type than substitute clustering due to
the concatenation of ${\bf W}$.  The advantage in highly ambiguous
words is still retained (e.g. the \mto\ for {\em offer} is .89) and
the overall result is significantly improved (.70 \mto) compared to
substitute clustering.
Section~\ref{sec:clustering-concatenation} presents our experiments
clustering concatenated word-substitute vectors.

\paragraph{Summary} The first setting applies the one-tag-per-word
assumption from the beginning and clusters word types instead of
tokens.  The second setting clusters word contexts (as represented by
substitutes) and is able to categorize individual word tokens.
However it ignores the identity of the target word.  The third setting
also clusters word tokens but represents each token with a set of
concatenated word and substitute embeddings.  Representing the
identity of the target word without enforcing the one-tag-per-word
assumption improves the results on highly ambiguous words.
Section~\ref{sec:exp} compares the performance of these three settings
on the part of speech induction problem, as well as experiments with
different features and languages.


\section{Semantics}
We use a variant of structural operational semantics~\cite{SOS2004Plotkin, HennessySemantics90} that relies heavily on valuation functions to define the semantics of \SLCO.
These valuation functions enable a compositional definition of the semantics.
The potential behavior of an \SLCO model is defined in terms of the potential behavior of the objects that constitute this model.
In turn, the potential behavior of the objects is defined in terms of the potential behavior of their classes, which is defined in terms of the potential behavior of the state machines that constitute the classes.
Finally, the potential behavior of a state machine is defined in terms of the potential behavior of the transitions of the state machine.

\subsection{Transitions}
The potential behavior of a transition is defined by the relation
%
\[
\TransitionsRelation{} ~ \subseteq (\Transitions \times \StateNames \times \VVARS \times \VVARS) \times \TransitionLabels \times (\StateNames \times \VVARS \times \VVARS),
\]

\noindent
where each function~$\vvars$ from the set of partial functions~$\VVARS = \VariableNames \pfun \ConstantExpressions$ maps variable names to constant expressions, and the syntax of transition labels~$l \in \TransitionLabels$ is defined as follows.
%
\[
\begin{array}{lcl}
\it{l} & ::= & \epsilon \\
        & |   & ``\textbf{send}"~\it{sgn}~``("~\it{ce^*}~``)"~``\textbf{to}"~\it{pn} \\
        & |   & ``\textbf{receive}"~\it{sgn}~``("~\it{ce^*}~``)"~``\textbf{from}"~\it{pn} \\
        & |   & ``\textbf{send}"~\it{sgn}~``("~\it{ce^*}~``)" \\
        & |   & ``\textbf{receive}"~\it{sgn}~``("~\it{ce^*}~``)" \\
        & |   & ``\textbf{lost}"~\it{sgn}~``("~\it{ce^*}~``)" \\
        & |   & \it{sgn}~``("~\it{ce^*}~``)" \\
        & |   & \it{vn}~``\assignop"~\it{ce} \\
\end{array}
\]

\noindent
The relation~\TransitionsRelation{} is the least relation satisfying the following rules.
%
\begin{equation*}
\langle \it{tn}~\textbf{from}~\it{sn}~\textbf{to}~\it{sn'}, \it{sn}, \vvars, \vvars' \rangle
\TransitionsRelation{\epsilon}
\langle \it{sn'}, \vvars, \vvars' \rangle
\tag{T1}
\label{eq:sos-slco:trans-empty}
\end{equation*}
%
\begin{equation*}
\sosrule{
\langle \it{e}, \vvars, \vvars' \rangle
\ExpressionRelation{}
\textbf{true}
}{
\langle \it{tn}~\textbf{from}~\it{sn}~\textbf{to}~\it{sn'}~\it{e}, \it{sn}, \vvars, \vvars' \rangle
\TransitionsRelation{\epsilon}
\langle \it{sn'}, \vvars, \vvars' \rangle
}
\tag{T2}
\label{eq:sos-slco:trans-expression}
\end{equation*}
%
\begin{equation*}
\sosrule{
\langle \it{assign}, \vvars, \vvars' \rangle
\AssignmentRelation{l}
\langle \vvars'', \vvars''' \rangle
}{
\langle \it{tn}~\textbf{from}~\it{sn}~\textbf{to}~\it{sn'}~\it{assign}, \it{sn}, \vvars, \vvars' \rangle
\TransitionsRelation{\it{l}}
\langle \it{sn'}, \vvars'', \vvars''' \rangle
}
\tag{T3}
\label{eq:sos-slco:trans-assignment}
\end{equation*}
%
\begin{equation*}
\sosrule{
\langle \it{e^*}, \vvars, \vvars' \rangle
\ExpressionsRelation{}
\it{ce^*}
}{
\langle \it{tn}~\textbf{from}~\it{sn}~\textbf{to}~\it{sn'}~\textbf{send}~\it{sign}(\it{e^*})~\textbf{to}~\it{pn}, \it{sn}, \vvars, \vvars' \rangle \\
\TransitionsRelation{\textbf{send}~\it{sgn}(\it{ce^*})~\textbf{to}~\it{pn}}
\langle \it{sn'}, \vvars, \vvars' \rangle
}
\tag{T4}
\label{eq:sos-slco:trans-send}
\end{equation*}
%
\begin{equation*}
\sosrule{
\langle \it{ce^*}, \it{vn^*}, \vvars, \vvars' \rangle
\MultipleSubstitutionRelation{}
\langle \vvars'', \vvars''' \rangle, \quad
\langle \it{e}, \vvars'', \vvars''' \rangle
\ExpressionRelation{}
\textbf{true}
}{
\langle \it{tn}~\textbf{from}~\it{sn}~\textbf{to}~\it{sn'}~\textbf{receive}~\it{sgn}(\it{vn^*}~|~\it{e})~\textbf{from}~\it{pn}, \it{sn}, \vvars, \vvars' \rangle \\
\TransitionsRelation{\textbf{receive}~\it{sgn}(\it{ce^*})~\textbf{from}~\it{pn}}
\langle \it{sn'}, \vvars'', \vvars''' \rangle
}
\tag{T5}
\label{eq:sos-slco:trans-reception}
\end{equation*}

Rule~\eqref{eq:sos-slco:trans-empty} defines that a transition specification~$\it{tn}~\textbf{from}~\it{sn}~\textbf{to}~\it{sn'}$ leads to a transition from state~$\it{sn}$ to state~$\it{sn'}$, leaving the valuation functions~\vvars and~$\vvars'$ unchanged.

Rule~\eqref{eq:sos-slco:trans-expression} defines that such a transition is also possible given a transition specification~$\it{tn}~\textbf{from}~\it{sn}~\textbf{to}~\it{sn'}~\it{e}$, provided that the expression~$e$ evaluates to~$\textbf{true}$.
This rule refers to a relation~$\ExpressionRelation{} ~ \subseteq (\Expressions \times \VVARS \times \VVARS) \times \ConstantExpressions$, which defines how expressions~$e \in \Expressions$ evaluate to constant expressions~$\it{ce} \in \ConstantExpressions$, given two valuation functions~$\vvars \in \VVARS$ and~$\vvars' \in \VVARS$.
We do not specify the syntax of expressions, as mentioned above, and leave their semantics unspecified as well.
We use a standard semantics for the evaluation of expressions, where two valuation functions are used to distinguish between the local variables of state machines and the global variables of objects.
This distinction is discussed in further detail below.

Rule~\eqref{eq:sos-slco:trans-assignment} defines that the execution of an assignment statement as part of a transition leads to an update of the valuation functions~$\vvars$ and $\vvars'$.
The rule refers to the relation~$\AssignmentRelation{} ~ \subseteq (\Expressions \times \VVARS \times \VVARS) \times \TransitionLabels \times (\VVARS \times \VVARS)$, which defines the details of this update.
The relation~\AssignmentRelation{} is the least relation satisfying the following rules.
%
\begin{equation*}
\sosrule{
\langle \it{e}, \vvars, \vvars' \rangle
\ExpressionRelation{}
\it{ce}, \quad
\it{vn} \in \operatorname{dom}(\vvars'), \quad
\vvars'' = \vvars'[\it{ce}/\it{vn}]
}{
\langle \it{vn}~\assignop~\it{e}, \vvars, \vvars' \rangle
\AssignmentRelation{\it{vn} \assignop \it{ce}}
\langle \vvars, \vvars'' \rangle
}
\end{equation*}
%
\begin{equation*}
\sosrule{
\langle \it{e}, \vvars, \vvars' \rangle
\ExpressionRelation{}
\it{ce}, \\
\it{vn} \notin \operatorname{dom}(\vvars'), \quad
\it{vn} \in \operatorname{dom}(\vvars), \quad
\vvars'' = \vvars[\it{ce}/\it{vn}]
}{
\langle \it{vn}~\assignop~\it{e}, \vvars, \vvars' \rangle
\AssignmentRelation{\it{vn} \assignop \it{ce}}
\langle \vvars'', \vvars' \rangle
}
\end{equation*}

\noindent
In these rules, the distinction between local and global variables becomes apparent.
In both rules, valuation function~\vvars maps the global variables to their values, and function~$\vvars'$ maps the local variables to their values.
If a local variable named~$\it{vn}$ exists, denoted by~$\it{vn} \in \operatorname{dom}(\vvars')$, then the valuation function~$\vvars'$ is updated by mapping~$\it{vn}$ to~$\it{ce}$.
Otherwise, if a global variable named~$\it{vn}$ exists, the valuation function~$\vvars$ is updated.
We use~$f[\it{v}/\it{x}]$ to denote the updated function~$f$, where~$f[\it{v}/\it{x}](x)=\it{v}$ and $f[\it{v}/\it{x}](y)=f(y)$ for all~$y \not = x$.

Rule~\eqref{eq:sos-slco:trans-send} defines the semantics of transitions with statements that send signals.
It refers to the relation~$\ExpressionsRelation{} ~ \subseteq (\it{SEQ}(\Expressions) \times \VVARS \times \VVARS) \times \it{SEQ}(\ConstantExpressions)$, which defines how a sequence of expressions is evaluated to a sequence of constant expressions, given two valuation functions.
The relation~$\ExpressionsRelation{}$ is the least relation that satisfies the following rules.
%
\begin{equation*}
\langle \epsilon, \vvars, \vvars' \rangle
\ExpressionsRelation{}
\epsilon
\end{equation*}
%
\begin{equation*}
\sosrule{
\langle \it{e}, \vvars, \vvars' \rangle
\ExpressionRelation{}
\it{ce}, \quad
\langle \it{e^*}, \vvars, \vvars' \rangle
\ExpressionsRelation{}
\it{ce^*}
}{
\langle \it{e}~\it{e^*}, \vvars, \vvars' \rangle
\ExpressionsRelation{}
\it{ce}~\it{ce^*}
}
\end{equation*}

Finally, an instance of rule~\eqref{eq:sos-slco:trans-reception} exists for all~$\it{ce^*} \in \it{SEQ}(\ConstantExpressions)$.
These instances define the semantics of transitions with signal reception statements.
It refers to the relation~$\MultipleSubstitutionRelation{} ~ \subseteq (\ConstantExpressions \times \VariableNames \times \VVARS \times \VVARS) \times (\VVARS \times \VVARS)$, which defines sequential updates of the values of a set of variables.
The relation~\MultipleSubstitutionRelation{} is the least relation satisfying the following rules.
%
\begin{equation*}
\langle \epsilon, \epsilon, \vvars, \vvars' \rangle
\MultipleSubstitutionRelation{}
\langle \vvars, \vvars' \rangle
\end{equation*}
%
\begin{equation*}
\sosrule{
\it{vn} \in \operatorname{dom}(\vvars'), \quad
\vvars'' = \vvars'[\it{ce}/\it{vn}], \quad
\langle \it{ce^*}, \it{vn^*}, \vvars, \vvars'' \rangle
\MultipleSubstitutionRelation{}
\langle \vvars''', \vvars'''' \rangle
}{
\langle \it{ce}~\it{ce^*}, \it{vn}~\it{vn^*}, \vvars, \vvars' \rangle
\MultipleSubstitutionRelation{}
\langle \vvars''', \vvars'''' \rangle
}
\end{equation*}

\begin{equation*}
\sosrule{
\it{vn} \notin \operatorname{dom}(\vvars'), \quad
\it{vn} \in \operatorname{dom}(\vvars), \quad
\vvars'' = \vvars[\it{ce}/\it{vn}], \\
\langle \it{ce^*}, \it{vn^*}, \vvars'', \vvars' \rangle
\MultipleSubstitutionRelation{}
\langle \vvars''', \vvars'''' \rangle
}{
\langle \it{ce}~\it{ce^*}, \it{vn}~\it{vn^*}, \vvars, \vvars' \rangle
\MultipleSubstitutionRelation{}
\langle \vvars''', \vvars'''' \rangle
}
\end{equation*}

\noindent
Each instance of rule~\eqref{eq:sos-slco:trans-reception} specifies that a statement~$\textbf{receive}~\it{sgn}(\it{vn^*}~|~\it{e})~\textbf{from}~\it{pn}$ is only enabled if expression~$e$ evaluates to~$\textbf{true}$ after updating the values of the variables~$\it{vn^*}$ to the constant expressions~$\it{ce^*}$.
This sequence of constant expressions represents the possible values of the arguments of signals sent by other objects.

\section{State Machines}
The potential behavior of a state machine is defined by the relation
%
\[
\StateMachineRelation{} ~ \subseteq (\StateMachines \times \SSMS \times \VVARS \times \VSMS) \times \TransitionLabels \times (\SSMS \times \VVARS \times \VSMS),
\]

\noindent
where each function~$\ssms$ from the set of partial functions~$\SSMS = \StateMachineNames \pfun \StateNames$ maps state machine names to state names, and each function~$\vsms$ from the set of partial functions~$\VSMS = \StateMachineNames \pfun (\VariableNames \pfun \ConstantExpressions)$ maps state machine names to functions that map variable names to constant expression.
The fact that state machine~$\it{smn}$ is in state~$\it{sn}$ is encoded as~$\ssms(\it{smn}) = \it{sn}$ using a function~$\ssms \in \SSMS$.
Furthermore, the fact that variable~$\it{vn}$ of state machine~$\it{smn}$ has the value~$\it{ce}$ is encoded as~$\vsms(\it{smn})(\it{vn}) = \it{ce}$ using a function~$\vsms \in \VSMS$.
The relation~\StateMachineRelation{} is the least relation satisfying the following rule.
%
\begin{equation*}
\sosrule{
\it{trans} \in \it{trans^*}, \\
\langle \it{trans}, \ssms(\it{smn}), \vvars, \vsms(\it{smn}) \rangle
\TransitionsRelation{l}
\langle \it{sn}, \vvars', \vvars'' \rangle, \\
\ssms' = \ssms[\it{sn}/\it{smn}], \quad
\vsms' = \vsms[\vvars''/\it{smn}]
}{
\langle \it{smn}~\it{var^*}~\it{states}~\it{trans^*}, \ssms, \vvars, \vsms \rangle
\StateMachineRelation{l}
\langle \ssms', \vvars', \vsms' \rangle
}
\tag{SM}
\label{eq:sos-slco:sm}
\end{equation*}

\noindent
We use~$\it{e} \in \it{e^*}$ to denote~$\exists e', e'' ~ . ~ e^* \equiv e'~e~e''$, for each element~$e$ of a syntactic category.

Rule~\eqref{eq:sos-slco:sm} defines that if one of the transitions of a state machine can go from state~$\ssms(\it{smn})$ to state~$\it{sn}$ while performing an action represented by~$l$, then this state machine can make a transition to the same state from state~$\ssms(\it{smn})$ while performing the same action.

\subsection{Classes}
The potential behavior of a class is defined by the relation
%
\[
\ClassRelation{} ~ \subseteq (\Classes \times \SSMS \times \VVARS \times \VSMS) \times \TransitionLabels \times (\SSMS \times \VVARS \times \VSMS).
\]

\noindent
The relation~\ClassRelation{} is the least relation satisfying the following rule.
%
\begin{equation*}
\sosrule{
\it{sm} \in \it{sm^*}, \quad
\langle \it{sm}, \ssms, \vvars, \vsms \rangle
\StateMachineRelation{l}
\langle \ssms', \vvars', \vsms' \rangle
}{
\langle \it{cn}~\it{var^*}~\it{port^*}~\it{sm^*}, \ssms, \vvars, \vsms \rangle
\ClassRelation{l}
\langle \ssms', \vvars', \vsms' \rangle
}
\tag{C}
\label{eq:sos-slco:class}
\end{equation*}

\noindent
Rule~\eqref{eq:sos-slco:class} defines that the potential behavior of a class is derived from the potential behavior of the state machines of that class.

\subsection{Objects}
The potential behavior of a set of objects is defined by the relation
%
\begin{align*}
\ObjectsRelation{} ~ \subseteq & ~ (\Objects \times \Classes \times \Channels \times \SOBJS \times \VGLOB \times \VLOC \times \Buf)\\
 & ~ \times \TransitionLabels \times (\SOBJS \times \VGLOB \times \VLOC \times \Buf),
\end{align*}

\noindent
where each function~$\vglob$ from the set of partial functions~$\VGLOB = \ObjectNames \pfun (\VariableNames \pfun \ConstantExpressions)$ maps object names to functions that map variable names to constant expressions,
each function~$\vloc$ from the set of partial functions~$\VLOC = \ObjectNames \pfun (\StateMachineNames \pfun (\VariableNames \pfun \ConstantExpressions))$ maps object names to functions that map state machine names to functions that map variable names to constant expressions,
each function~$\sobjs$ from the set of partial functions~$\SOBJS = \ObjectNames \pfun (\StateMachineNames \pfun \StateNames)$ maps object names to functions that map state machine names to state names,
and each function~$\buf$ from the set of partial functions~$\Buf = (\ChannelNames \times \ObjectNames \times \ObjectNames) \pfun (\SignalNames \times {\it SEQ}(\ConstantExpressions)) \cup \{\nil\}$ maps tuples consisting of a channel name and two object names to the constant nil or a tuple consisting of a signal name and a sequence of constant expressions.
The functions in~\VGLOB encode valuations of global variables, and the functions in~\VLOC encode valuations of local variables.
The set of functions~\SOBJS is an extension of the set~\SSMS.
The fact that state machine~$\it{smn}$ of object~$\it{on}$ is in state~$\it{sn}$ is encoded as~$\sobjs(\it{on})(\it{smn}) = \it{sn}$ using a function~$\sobjs \in \SOBJS$.
The functions in~$\Buf$ are used to encode the content of a set of buffers.
The fact that the buffer corresponding to the channel~$\it{chn}$ that connects objects~$\it{on_1}$ and~$\it{on_2}$ is empty is encoded as~$\buf(\it{chn}, \it{on_1}, \it{on_2}) = \nil$ using a function~$\buf \in \Buf$.
In the remainder of this section, we discuss a number of the rules that define this relation.

The following rule defines the part of the semantics of sequences of objects related to assignment statements.
%
\begin{equation*}
\sosrule{
\it{on}:\it{cn} \in \it{obj^*}, \quad
\it{cn}~\it{var^*}~\it{pn^*}~\it{sm^*} \in \it{class^*}, \\
\langle \it{cn}~\it{var^*}~\it{pn^*}~\it{sm^*}, \sobjs(\it{on}), \vglob(\it{on}), \vloc(\it{on}) \rangle \\
\ClassRelation{\it{vn} \assignop \it{ce}}
\langle \ssms, \vvars, \vsms \rangle, \\
\sobjs' = \sobjs[\ssms/\it{on}], \quad
\vglob' = \vglob[\vvars/\it{on}], \quad
\vloc' = \vloc[\vsms/\it{on}]
}{
\langle \it{obj^*}, \it{class^*}, \it{chan^*}, \sobjs, \vglob, \vloc, \buf \rangle
\ObjectsRelation{\it{vn} \assignop \it{ce}}
\langle \sobjs', \vglob', \vloc', \buf \rangle
}
\tag{O1}
\label{eq:sos-slco:object-assign}
\end{equation*}

\noindent
Rule~\eqref{eq:sos-slco:object-assign} specifies that a sequence of objects can perform an assignment~$\it{vn} \assignop \it{ce}$ if one of the objects in the sequence is an instance of a class that can perform this assignment.

The following rules defines the part of the semantics of sequences of objects related to synchronous communication.
%
\begin{equation*}
\sosrule{
\it{on_1}:\it{cn_1} \in \it{obj^*}, \quad
\it{on_2}:\it{cn_2} \in \it{obj^*}, \\
\it{cn_1}~\it{var^*_1}~\it{pn^*_1}~\it{sm^*_1} \in \it{class^*}, \quad
\it{cn_2}~\it{var^*_2}~\it{pn^*_2}~\it{sm^*_2} \in \it{class^*}, \\
\it{chn}(\it{type^*})~\textbf{sync}~\textbf{from}~\it{on_1}.\it{pn_1}~\textbf{to}~\it{on_2}.\it{pn_2} \in \it{chan^*}, \\
\langle \it{cn_1}~\it{var^*_1}~\it{pn^*_1}~\it{sm^*_1}, \sobjs(\it{on_1}), \vglob(\it{on_1}), \vloc(\it{on_1}) \rangle \\
\ClassRelation{\textbf{send}~\it{sgn}(\it{ce^*})~\textbf{to}~\it{pn_1}}
\langle \ssms, \vvars, \vsms \rangle, \\
\langle \it{cn_2}~\it{var^*_2}~\it{pn^*_2}~\it{sm^*_2}, \sobjs(\it{on_2}), \vglob(\it{on_2}), \vloc(\it{on_2}) \rangle \\
\ClassRelation{\textbf{receive}~\it{sgn}(\it{ce^*})~\textbf{from}~\it{pn_2}}
\langle \ssms', \vvars', \vsms' \rangle, \\
\sobjs' = \sobjs[\ssms/\it{on_1}][\ssms'/\it{on_2}], \\
\vglob' = \vglob[\vvars'/\it{on_2}], \quad
\vloc' = \vloc[\vsms'/\it{on_2}]
}{
\langle \it{obj^*}, \it{class^*}, \it{chan^*}, \sobjs, \vglob, \vloc, \buf \rangle
\ObjectsRelation{\it{sn}(\it{ce^*})}
\langle \sobjs', \vglob', \vloc', \buf \rangle
}
\tag{O2}
\label{eq:sos-slco:object-syncuni}
\end{equation*}
%
\begin{equation*}
\sosrule{
\it{on_1}:\it{cn_1} \in \it{obj^*}, \quad
\it{on_2}:\it{cn_2} \in \it{obj^*}, \\
\it{cn_1}~\it{var^*_1}~\it{pn^*_1}~\it{sm^*_1} \in \it{class^*}, \quad
\it{cn_2}~\it{var^*_2}~\it{pn^*_2}~\it{sm^*_2} \in \it{class^*}, \\
\it{chn}(\it{type^*})~\textbf{sync}~\textbf{between}~\it{on_1}.\it{pn_1}~\textbf{and}~\it{on_2}.\it{pn_2} \in \it{chan^*}, \\
\langle \it{cn_1}~\it{var^*_1}~\it{pn^*_1}~\it{sm^*_1}, \sobjs(\it{on_1}), \vglob(\it{on_1}), \vloc(\it{on_1}) \rangle \\
\ClassRelation{\textbf{send}~\it{sgn}(\it{ce^*})~\textbf{to}~\it{pn_1}}
\langle \ssms, \vvars, \vsms \rangle, \\
\langle \it{cn_2}~\it{var^*_2}~\it{pn^*_2}~\it{sm^*_2}, \sobjs(\it{on_2}), \vglob(\it{on_2}), \vloc(\it{on_2}) \rangle \\
\ClassRelation{\textbf{receive}~\it{sgn}(\it{ce^*})~\textbf{from}~\it{pn_2}}
\langle \ssms', \vvars', \vsms' \rangle, \\
\sobjs' = \sobjs[\ssms/\it{on_1}][\ssms'/\it{on_2}], \\
\vglob' = \vglob[\vvars'/\it{on_2}], \quad
\vloc' = \vloc[\vsms'/\it{on_2}]
}{
\langle \it{obj^*}, \it{class^*}, \it{chan^*}, \sobjs, \vglob, \vloc, \buf \rangle
\ObjectsRelation{\it{sn}(\it{ce^*})}
\langle \sobjs', \vglob', \vloc', \buf \rangle
}
\tag{O3}
\label{eq:sos-slco:object-syncbi1}
\end{equation*}
%
\begin{equation*}
\sosrule{
\it{on_1}:\it{cn_1} \in \it{obj^*}, \quad
\it{on_2}:\it{cn_2} \in \it{obj^*}, \\
\it{cn_1}~\it{var^*_1}~\it{pn^*_1}~\it{sm^*_1} \in \it{class^*}, \quad
\it{cn_2}~\it{var^*_2}~\it{pn^*_2}~\it{sm^*_2} \in \it{class^*}, \\
\it{chn}(\it{type^*})~\textbf{sync}~\textbf{between}~\it{on_2}.\it{pn_2}~\textbf{and}~\it{on_1}.\it{pn_1} \in \it{chan^*}, \\
\langle \it{cn_1}~\it{var^*_1}~\it{pn^*_1}~\it{sm^*_1}, \sobjs(\it{on_1}), \vglob(\it{on_1}), \vloc(\it{on_1}) \rangle \\
\ClassRelation{\textbf{send}~\it{sgn}(\it{ce^*})~\textbf{to}~\it{pn_1}}
\langle \ssms, \vvars, \vsms \rangle, \\
\langle \it{cn_2}~\it{var^*_2}~\it{pn^*_2}~\it{sm^*_2}, \sobjs(\it{on_2}), \vglob(\it{on_2}), \vloc(\it{on_2}) \rangle \\
\ClassRelation{\textbf{receive}~\it{sgn}(\it{ce^*})~\textbf{from}~\it{pn_2}}
\langle \ssms', \vvars', \vsms' \rangle, \\
\sobjs' = \sobjs[\ssms/\it{on_1}][\ssms'/\it{on_2}], \\
\vglob' = \vglob[\vvars'/\it{on_2}], \quad
\vloc' = \vloc[\vsms'/\it{on_2}]
}{
\langle \it{obj^*}, \it{class^*}, \it{chan^*}, \sobjs, \vglob, \vloc, \buf \rangle
\ObjectsRelation{\it{sn}(\it{ce^*})}
\langle \sobjs', \vglob', \vloc', \buf \rangle
}
\tag{O4}
\label{eq:sos-slco:object-syncbi2}
\end{equation*}

\noindent
Rule~\eqref{eq:sos-slco:object-syncuni} specifies synchronous communication between two objects over a unidirectional channel, and Rules~\eqref{eq:sos-slco:object-syncbi1} and~\eqref{eq:sos-slco:object-syncbi2} specify synchronous communication over bidirectional channels.
Because sending a signal does not affect the valuation of variables, the updates of~\vglob and~\vloc do not take object~$\it{on_1}$ into account.

The following rules define asynchronous communication over a lossless channel.
%
\begin{equation*}
\sosrule{
\it{on_1}:\it{cn_1} \in \it{obj^*}, \quad
\it{cn_1}~\it{var^*_1}~\it{pn^*_1}~\it{sm^*_1} \in \it{class^*}, \\
\it{chn}(\it{type^*})~\textbf{async lossless}~\textbf{from}~\it{on_1}.\it{pn_1}~\textbf{to}~\it{on_2}.\it{pn_2} \in \it{chan^*}, \\
\langle \it{cn_1}~\it{var^*_1}~\it{pn^*_1}~\it{sm^*_1}, \sobjs(\it{on_1}), \vglob(\it{on_1}), \vloc(\it{on_1}) \rangle \\
\ClassRelation{\textbf{send}~\it{sgn}(\it{ce^*})~\textbf{to}~\it{pn_1}}
\langle \ssms, \vvars, \vsms \rangle, \\
\sobjs' = \sobjs[\ssms/\it{on_1}], \\
\buf(\langle \it{chn}, \it{on_1}, \it{on_2} \rangle) = \textbf{nil}, \quad
\buf' = \buf[\langle \it{sgn}, \it{ce^*} \rangle/\langle \it{chn}, \it{on_1}, \it{on_2} \rangle]
}{
\langle \it{obj^*}, \it{class^*}, \it{chan^*}, \sobjs, \vglob, \vloc, \buf \rangle
\ObjectsRelation{\textbf{send}~\it{sgn}(\it{ce^*})}
\langle \sobjs', \vglob, \vloc, \buf' \rangle
}
\tag{O5}
\label{eq:sos-slco:object-async1}
\end{equation*}
%
\begin{equation*}
\sosrule{
\it{on_2}:\it{cn_2} \in \it{obj^*}, \quad
\it{cn_2}~\it{var^*_2}~\it{pn^*_2}~\it{sm^*_2} \in \it{class^*}, \\
\it{chn}(\it{type^*})~\textbf{async lossless}~\textbf{from}~\it{on_1}.\it{pn_1}~\textbf{to}~\it{on_2}.\it{pn_2} \in \it{chan^*}, \\
\langle \it{cn_2}~\it{var^*_2}~\it{pn^*_2}~\it{sm^*_2}, \sobjs(\it{on_2}), \vglob(\it{on_2}), \vloc(\it{on_2}) \rangle \\
\ClassRelation{\textbf{receive}~\it{sgn}(\it{ce^*})~\textbf{from}~\it{pn_2}}
\langle \ssms, \vvars, \vsms \rangle, \\
\sobjs' = \sobjs[\ssms/\it{on_2}], \\
\vglob' = \vglob[\vvars/\it{on_2}], \quad
\vloc' = \vloc[\vsms/\it{on_2}], \\
\buf(\langle \it{chn}, \it{on_1}, \it{on_2} \rangle) = \langle \it{sgn}, \it{ce^*} \rangle, \quad
\buf' = \buf[\textbf{nil}/\langle \it{chn}, \it{on_1}, \it{on_2} \rangle]
}{
\langle \it{obj^*}, \it{class^*}, \it{chan^*}, \sobjs, \vglob, \vloc, \buf \rangle \\
\ObjectsRelation{\textbf{receive}~\it{sgn}(\it{ce^*})}
\langle \sobjs', \vglob', \vloc', \buf' \rangle
}
\tag{O6}
\label{eq:sos-slco:object-async2}
\end{equation*}

\noindent
We only give the rules related to unidirectional channels.
The rules for bidirectional channels are similar, however, and can be derived from the rules given above.

Rule~\eqref{eq:sos-slco:object-async1} specifies that a signal is placed in the buffer that corresponds to an asynchronous channel if an object sends this signal over the channel.
This is only possible if the buffer is empty when the statement is executed.
Rule~\eqref{eq:sos-slco:object-async2} specifies that a signal is removed from the buffer that corresponds to an asynchronous channel if an object that is connected to this channel is able to receive this signal.

The following rules define how asynchronous communication over a lossy channel differs from asynchronous communication over a lossless channel.
%
\begin{equation*}
\sosrule{
\it{on_1}:\it{cn_1} \in \it{obj^*}, \quad
\it{cn_1}~\it{var^*_1}~\it{pn^*_1}~\it{sm^*_1} \in \it{class^*}, \\
\it{chn}(\it{type^*})~\textbf{async lossy}~\textbf{from}~\it{on_1}.\it{pn_1}~\textbf{to}~\it{on_2}.\it{pn_2} \in \it{chan^*}, \\
\langle \it{cn_1}~\it{var^*_1}~\it{pn^*_1}~\it{sm^*_1}, \sobjs(\it{on_1}), \vglob(\it{on_1}), \vloc(\it{on_1}) \rangle \\
\ClassRelation{\textbf{send}~\it{sgn}(\it{ce^*})~\textbf{to}~\it{pn_1}}
\langle \ssms, \vvars, \vsms \rangle, \\
\sobjs' = \sobjs[\ssms/\it{on_1}]
}{
\langle \it{obj^*}, \it{class^*}, \it{chan^*}, \sobjs, \vglob, \vloc, \Buf \rangle
\ObjectsRelation{\textbf{lost}~\it{sgn}(\it{ce^*})}
\langle \sobjs', \vglob', \vloc', \Buf \rangle
}
\tag{O7}
\label{eq:sos-slco:object-lossy1}
\end{equation*}
%
\begin{equation*}
\sosrule{
\it{on_1}:\it{cn_1} \in \it{obj^*}, \quad
\it{cn_1}~\it{var^*_1}~\it{pn^*_1}~\it{sm^*_1} \in \it{class^*}, \\
\it{chn}(\it{type^*})~\textbf{async lossy}~\textbf{from}~\it{on_1}.\it{pn_1}~\textbf{to}~\it{on_2}.\it{pn_2} \in \it{chan^*}, \\
\langle \it{cn_1}~\it{var^*_1}~\it{pn^*_1}~\it{sm^*_1}, \sobjs(\it{on_1}), \vglob(\it{on_1}), \vloc(\it{on_1}) \rangle \\
\ClassRelation{\textbf{send}~\it{sgn}(\it{ce^*})~\textbf{to}~\it{pn_1}}
\langle \ssms, \vvars, \vsms \rangle, \\
\sobjs' = \sobjs[\ssms/\it{on_1}], \\
\buf(\langle \it{chn}, \it{on_1}, \it{on_2} \rangle) = \langle \it{sgn'}, \it{ce^{*\prime}} \rangle, \quad
\buf' = \buf[\langle \it{sgn}, \it{ce^*} \rangle/\langle \it{chn}, \it{on_1}, \it{on_2} \rangle]
}{
\langle \it{obj^*}, \it{class^*}, \it{chan^*}, \sobjs, \vglob, \vloc, \buf \rangle
\ObjectsRelation{\textbf{lost}~\it{sgn'}(\it{ce^{*\prime}})}
\langle \sobjs', \vglob', \vloc', \buf' \rangle
}
\tag{O8}
\label{eq:sos-slco:object-lossy2}
\end{equation*}

\noindent
Besides the rules shown above, additional rules exist that complete the definition of asynchronous communication over lossy channels.
These rules are similar to the rules defining communication over asynchronous, lossless channels and can be derived from those rules.

Rule~\eqref{eq:sos-slco:object-lossy1} specifies that a signal sent over a lossy channel may get lost.
In this rule, the function representing the buffer is unchanged.
Rule~\eqref{eq:sos-slco:object-lossy2} specifies an alternative way of losing signals.
It shows that a signal sent over a lossy channel can be placed in the corresponding buffer, even if this buffer already contains a signal.
The new signal replaces the existing signal, which means that the original signal is lost.

\subsection{Models}
Finally, the potential behavior of a model is defined by the relation
%
\begin{align*}
\ModelRelation{} ~ \subseteq & ~ (\Models \times \SOBJS \times \VGLOB \times \VLOC \times \Buf) \\
 & ~ \times \TransitionLabels \times (\Models \times \SOBJS \times \VGLOB \times \VLOC \times \Buf),
\end{align*}

\noindent
which is the least relation satisfying the following rule.
%
\begin{equation*}
\sosrule{
\it{m} \equiv \it{mn}~\it{obj^*}~\it{class^*}~\it{chan^*}, \\
\langle \it{obj^*}, \it{class^*}, \it{chan^*}, \sobjs, \vglob, \vloc, \buf \rangle
\ObjectsRelation{l}
\langle \sobjs', \vglob', \vloc', \buf' \rangle
}{
\langle \it{m}, \sobjs, \vglob, \vloc, \buf \rangle
\ModelRelation{l}
\langle \it{m}, \sobjs', \vglob', \vloc', \buf' \rangle
}
\tag{M}
\label{eq:sos-slco:model}
\end{equation*}


\section{Conclusion}

%%%%%%%%%%%%%%%
\begin{frame}{}
  The idea of {\large ``\blue{parameterized} and \red{runtime-tunable} snapshot isolation''}.

  \vspace{0.80cm}
  \blue{\rvsi{}}: Relaxed Version Snapshot Isolation
  \begin{equation*}
    h \in \rvsi{} \iff h \in \konebv{} \cap \ktwofv{} \cap \kthreesv{} \cap \wcf{}
  \end{equation*}

  \vspace{0.30cm}
  \red{\chameleon{}}: a prototype distributed transactional key-value store
  \begin{itemize}
    \item Allows each transaction to tune its consistency level at runtime
    \item Evaluates the impacts of \rvsi{} on the transaction abort rates
  \end{itemize}
\end{frame}
%%%%%%%%%%%%%%%

%%%%%%%%%%%%%%%
\begin{frame}{}
  Two possible future work:
  \begin{itemize}
    \item To evaluate the impacts of \blue{$\kthreesv$} on transaction abort rates,
      probably with data mining technologies
    \item To study the impacts/anomalies of \rvsi{} from the perspectives of \blue{developers}
  \end{itemize}
\end{frame}
%%%%%%%%%%%%%%%

%%%%%%%%%%%%%%%
\begin{frame}[noframenumbering]
  \fignocaption{width = 0.20\textwidth}{figs/qa.png}
  \vspace{-0.8cm}
  \begin{center}
    \textcolor{blue}{\bf \large hfwei@nju.edu.cn}
  \end{center}
  \vspace{-0.5cm}
  \fignocaption{width = 0.50\textwidth}{figs/thankyou.jpg}
\end{frame}
%%%%%%%%%%%%%%%


% Time-Variable Input

In earlier versions of MODFLOW, most stress-boundary packages read input on a stress period-by-stress period basis, and those values were held constant during the stress period. In \programname{}, many stress values can be specified with a higher degree of time resolution (from time step to time step or from subtime step to subtime step) by using one of two time-variable approaches. Boundaries for which data are read as lists of cells can reference ``time series'' to implement the time variation. Boundaries for which data are read as 2-D arrays can reference ``time-array series'' to do so.

When \programname{} needs data from a time series or time-array series for a time interval representing a time step or subtime step, the series is queried to provide a time-averaged value or array of values for the requested time interval.  For each series, the user specifies an interpolation method that determines how the value is assumed to behave between listed times. The interpolation method thus determines how the time averaging is performed. When a time-array series is used, interpolation is performed on an element-by-element basis to generate a 2-D array of interpolated values as needed.

The supported interpolation methods are STEPWISE, LINEAR, and LINEAREND. When the STEPWISE interpolation method is used, the value is assumed to remain constant at the value specified in one time-series record until the time listed in the subsequent record, when the value changes abruptly to the new value. In the LINEAR interpolation method, the value is assumed to change linearly between times listed in sequential records. LINEAREND is like LINEAR, except that instead of using the average value over a time step, the value at the end of a time step is used. Following sections document the structure of time-series and time-array-series files and their use.

% Time series
\subsection{Time Series}

Any package that reads data as a list of cells and associated time-dependent input values can obtain those values from time series. For example, flow rates for a well or stage for a river boundary can be extracted from time series. During a simulation, values used for time-varying stresses (or auxiliary values) are based on the values provided in the time series and are updated each time step (or each subtime step, as appropriate). Input to define and use time series is described in this section.

A time series consists of a chronologically ordered list of time-series records, where each record includes a discrete time and a corresponding value. The value can be used to provide any time-varying numeric input, including stresses and auxiliary variables. A time series can be referenced in input for one or multiple variables in a given package.

% Time-series files
\subsubsection{Time-Series Files}

Each time-series file is associated with exactly one package, and the name of a time-series file associated with a package is listed in the OPTIONS block for the package, preceded by the keywords ``TS6 FILEIN.'' Any number of time-series files can be associated with a given package; a TS6 entry is required for each time-series file. A time-series file can contain one or more time series. Time-series files are not listed in either the simulation Name File or the model Name File. A given time-series file cannot be associated with more than one package.  By convention, the extension ``.ts'' is used in names of time-series files.

Each time-series file contains an ATTRIBUTES block followed by a TIMESERIES block containing a series of lines, where each line contains a time followed by values for one or more time series at the specified time. The ATTRIBUTES block is required to define the name for each time series and the interpolation method to be used when an operation requires interpolation between times listed in the time series.

The time-series name(s) and interpolation method(s) are specified in the ATTRIBUTES block. Scale factor(s) for multiplying values optionally can be provided in the ATTRIBUTES block. NAME, METHOD, METHODS, SFAC, and SFACS are keywords. For appearance when a time-series file includes multiple time series, NAMES can be used as a synonym for the NAME keyword.

The syntax of the ATTRIBUTES block for a time-series file containing a single time series is as follows:

% ATTRIBUTES block of TS6 file for a single time series
\begin{lstlisting}[style=blockdefinition]
BEGIN ATTRIBUTES
  NAME    time-series-name
  METHOD  interpolation-method
  [ SFAC  sfac ]
END ATTRIBUTES
\end{lstlisting}

When a time-series file contains multiple time series, the time-series names are listed in a NAME (or NAMES) entry, similar to the example above. If the time series are to have different interpolation methods, the METHODS keyword is used in place of the METHOD keyword, and an interpolation method corresponding to each name is listed. If the time series are to have different scale factors, the SFACS keyword is used in place of the SFAC keyword.

The syntax of the ATTRIBUTES block for a time-series file containing multiple time series is as follows:

% ATTRIBUTES block of TS6 file for multiple time series
\begin{lstlisting}[style=blockdefinition]
BEGIN ATTRIBUTES
  NAMES    time-series-name-1  [ time-series-name-2 ... time-series-name-n ]
  METHODS  interpolation-method-1  [ interpolation-method-2 ... ]
  [ SFACS  sfac-1  [ sfac-2 ... sfac-n ] ]
END ATTRIBUTES
\end{lstlisting}

In a case where a time-series file contains multiple time series and a single interpolation method applies to all time series in the file, the METHOD keyword can be used, and a single interpolation method is read. Similary, if a single scale factor applies to all time series in the file, the SFAC keyword can be used, and a single scale factor is read.

The ATTRIBUTES block is followed by a TIMESERIES block of the form:
\begin{lstlisting}[style=blockdefinition]
BEGIN TIMESERIES
  time-series record
  time-series record
  ...
  time-series record
END TIMESERIES
\end{lstlisting}

\noindent where each time-series record is of the form:\\
\begin{lstlisting}[style=blockdefinition]
  tsr-time  tsr-value-1  [ tsr-value-2  tsr-value-3  ... ]
\end{lstlisting}

In situations where an individual time series in a file containing multiple time series does not include values for all specified times, a ``no-data'' value (3.0E30) can be used as a placeholder. When the ``no-data'' value is read for a time series, that time series will not include a time-series record for the corresponding time.

% Explanation of Variables (Time-Series File)
\subsubsection{Explanation of Variables}

% time-series-name description
\begin{description}
\item \texttt{time-series-name}---Name by which a package references a particular time series. The name must be unique among all time series used in a package.
\end{description}

% interpolation-method description
\begin{description}
\item \texttt{interpolation-method}---Interpolation method, which is either STEPWISE, LINEAR, or LINEAREND.
\end{description}

% sfac description
\begin{description}
\item \texttt{sfac}---Scale factor, which will multiply all \texttt{tsr-value} values in the time series. SFAC and SFACS are optional attributes; if omitted, \texttt{sfac} = 1.0.
\end{description}

% tsr-time description
\begin{description}
\item \texttt{tsr-time}---A numeric time relative to the start of the simulation, in the time unit used in the simulation. Times must be strictly increasing.
\end{description}

% tsr-value description
\begin{description}
\item \texttt{tsr-value}---A numeric data value corresponding to tsr-time. The value 3.0E30 is treated as a ``no-data'' value and can be used wherever a time series in a file containing multiple time series does not have a value corresponding to the time specified by \texttt{tsr-time}.
\end{description}

%\vspace{5mm}

% Using time series in a package
\subsubsection{Using Time Series in a Package}

When one or more time series are to define numeric input for a package, the name(s) of time-series files need to be defined in an OPTIONS block at the top of the package input file. The keyword TS6 followed by the keyword FILEIN are used to identify the name of each time-series file. Each time-series file can contain one or more time series, and each OPTIONS block can contain zero or more TS6 entries. The syntax for a TS6 entry in an OPTIONS block is:

% OPTIONS block: syntax for TIMESERIESFILE
\begin{lstlisting}[style=blockdefinition]
BEGIN OPTIONS
  TS6  FILEIN  time-series-file-name
END OPTIONS
\end{lstlisting}

% Explanation of Variables Read from a Package Input File
\noindent \textbf{Explanation of Variables Read from a Package Input File:}

% time-series-name description
\begin{description}
\item \texttt{TS6}---Keyword to specify that record corresponds to a time-series file.
\item \texttt{FILEIN}---Keyword to specify that an input filename is expected next.
\item \texttt{time-series-file-name}---Name of a time-series file in which time series used in the package are defined.
\end{description}

Each time series has a name. To specify that time-dependent values for one or more stress periods is to be extracted from a time series, the time-series name is listed in the position where a numeric value normally would be provided.

\vspace{5 mm}

% Example use of time series
\noindent \textbf{Example use of time series to define package input}

The following example illustrates the use of three time series in input for the Well Package in a model with a structured grid. For an unstructured grid, the layer, row, and column indices for each observation would be replaced by a node number.

\vspace{5 mm}

%Contents of file well_pump_rates.ts:
Contents of file ``well\_pump\_rates.ts'':
\begin{lstlisting}[style=inputfile]
BEGIN ATTRIBUTES
  NAMES well-A-series well-B-series well-C-series
  METHODS stepwise linear stepwise
END ATTRIBUTES

BEGIN TIMESERIES
  # time  well-A-series     well-B-series     well-C-series
  0.0           0.0               0.0               0.0
  1.0        -500.0               0.0            -400.0
  2.0        -500.0           -1000.0            -500.0
  5.0        -500.0           -1200.0            -200.0
  8.0        -500.0           -1100.0               0.0
END TIMESERIES
\end{lstlisting}

Contents of the Well Package input file:
\begin{lstlisting}[style=inputfile]
BEGIN OPTIONS
  TS6 FILEIN  well_pump_rates.ts
END OPTIONS

BEGIN DIMENSIONS
  MAXBOUND 4
END DIMENSIONS

BEGIN PERIOD 2
  #layer  row  col  Q (or time series)
       9  192   44  well-A-series
      10   43   17  well-B-series
      11   12   17  well-C-series
END PERIOD

BEGIN PERIOD 4
  #layer  row  col  Q (or time series)
       9  192   44  well-A-series
      10   43   17  well-B-series
      11   12   17  well-C-series
       2   27   36   -900.0
END PERIOD

BEGIN PERIOD 8
       2   27   36   -900.0
END PERIOD
\end{lstlisting}

In the example above, the Well package would have zero wells active in stress period 1. Three wells whose discharge rates are controlled by time series well-A-series, well-B-series, and well-C-series would be active in stress periods 2 and 3. Stress periods 4 through 7 would include the three time-series-controlled wells plus a well with a constant discharge of 900 (L\textsuperscript{3}/T). In stress period 8, only the constant-discharge well would be active.

% Time-Array Series
\subsection{Time-Array Series}

Any package that reads data for a structured model in the form of 2-D arrays can obtain those array data from a time-array series. For example, recharge rates or maximum evapotranspiration rates can be extracted from time-array series. During a simulation, values used for time-varying stresses (or auxiliary values) are based on the values provided in the time-array series and are updated each time step (or each subtime step, as appropriate). Input to define and use time-array series is described in this section.

A time-array series consists of a chronologically ordered list of arrays, where each array is associated with a discrete time. The array data can be used to provide any time-varying, array-based numeric input.

% Time-Array-Series Files
\subsubsection{Time-Array-Series Files}

Each time-array-series file is associated with exactly one package, and the name of a time-array-series file associated with a package is listed in the OPTIONS block for the package, preceded by the keywords ``TAS6 FILEIN.'' Any number of time-array-series files can be associated with a given package; a TAS6 entry is required for each time-array-series file. Time-array-series files are not listed in either the simulation Name File or the model Name File. A given time-array-series file cannot be associated with more than one package.

One time-array-series file defines a single time-array series. A time-array-series file contains an ATTRIBUTES block followed by a series of TIME blocks, where each TIME block contains data to define an array corresponding to a discrete time. The READARRAY array reading utility is used to read the array. The ATTRIBUTES block is required to define the name for the time-array series and the interpolation method to be used when an operation requires interpolation between times listed in the time-array series.  By convention, the extension ``.tas'' is used in names of time-array-series files.

The syntax of the ATTRIBUTES block for a time-array-series file is as follows:

% ATTRIBUTES block of Time-Array-Series file
\begin{lstlisting}[style=blockdefinition]
BEGIN ATTRIBUTES
  NAME    time-array-series-name
  METHOD  interpolation-method
  [ SFAC  sfac ]
END ATTRIBUTES
\end{lstlisting}

The ATTRIBUTES block is followed by any number of TIME blocks of the form:\\
\begin{lstlisting}[style=blockdefinition]
BEGIN TIME tas-time
  tas-array
END TIME
\end{lstlisting}

% Explanation of Variables (Time-Array-Series File)
\subsubsection{Explanation of Variables}

% time-array-series-name description
\begin{description}
\item \texttt{time-array-series-name}---Name by which a package references a particular time-array series. The name must be unique among all time-array series used in a package.
\end{description}

% interpolation-method description
\begin{description}
\item \texttt{interpolation-method}---Interpolation method, which is either STEPWISE or LINEAR.
\end{description}

% tas-time description
\begin{description}
\item \texttt{sfac}---Scale factor, which will multiply all array values in time series. SFAC is an optional attribute; if omitted, SFAC = 1.0.
\end{description}

% tas-time description
\begin{description}
\item \texttt{tas-time}---A numeric time relative to the start of the simulation, in the time unit used in the simulation. Times must be strictly increasing.
\end{description}

% tas-array description
\begin{description}
\item \texttt{tas-array}---A 2-D array of numeric, floating-point values, or a constant value, readable by the READARRAY array-reading utility.
\end{description}

% Using Time-Array Series in a Package
\subsubsection{Using Time-Array Series in a Package}
When one or more time-array series are to define numeric input for a package, the name(s) of time-array-series file(s) need to be defined in an OPTIONS block at the top of the package input file. The keywords ``TAS6 FILEIN'' are used to identify the name of each time-array-series file. Each time-array-series file contains exactly one time-array series, and each OPTIONS block can contain zero or more TAS6 entries. The syntax for a TAS6 entry in an OPTIONS block is:

% OPTIONS block: syntax for TIMEARRAYSERIESFILE
\begin{lstlisting}[style=blockdefinition]
BEGIN OPTIONS
  TAS6 FILEIN  time-array-series-file-name
END OPTIONS
\end{lstlisting}

A time-array series is linked to an array in one or more stress period blocks used to define package input. To indicate that an array is to be controlled by a time-array series, the array property word is followed by the keyword TIMEARRAYSERIES and the time-array series name. When the TIMEARRAYSERIES keyword is found (and the array to be populated supports time-array series), the array reader is not invoked. Consequently, the array-control record and any associated input are omitted. The syntax to define the link is:

% Syntax for stress period block
\begin{lstlisting}[style=blockdefinition]
BEGIN PERIOD kper
  property-name TIMEARRAYSERIES time-array-series-name
END PERIOD
\end{lstlisting}

% Explanation of Variables Read from a Package Input File
\noindent \textbf{Explanation of Variables Read from a Package Input File:}

% time-array-series-name description
\begin{description}
\item \texttt{TAS6}---Keyword to specify that record corresponds to a time-array-series file.
\item \texttt{FILEIN}---Keyword to specify that an input filename is expected next.
\item \texttt{time-array-series-file-name}---Name of a time-array-series file in which a time-array series used in the package is defined.
\end{description}

\begin{description}
\item \texttt{property-name}---Name of property represented by array to be controlled by a time-array series.
\end{description}

\begin{description}
\item \texttt{time-array-series-name}---Name of time-array series. The time-array series must be defined in one of the files listed in the OPTIONS block with the TAS6 FILEIN keywords.
\end{description}

\vspace{5 mm}

% Example use of time-array series
\noindent \textbf{Example use of time-array series to define package input}

The following example illustrates the use of a time-array series to control the Recharge property of the Recharge package in a model with a structured grid. In this example time-array series values are obtained from the time-array series ``RchArraySeries\_1'' defined in file ``rch\_time\_array\_series.tas.'' The RchMult array is an auxiliary-variable array that is identified by the AUXMULTNAME keyword to be a multiplier for the recharge array. Accordingly, the recharge array is defined each time step as the element-by-element product of values interpolated from the ``RchArraySeries\_1'' time-array series and values from the auxiliary-variable RchMult array.

\vspace{5 mm}

Contents of Recharge package input file:

\begin{lstlisting}[style=inputfile]
BEGIN OPTIONS
  READASARRAYS
  AUX RchMult
  TAS6 FILEIN rch_time_array_series.tas
  AUXMULTNAME RchMult
  PRINT_INPUT
END OPTIONS

BEGIN PERIOD 1
  IRCH
    CONSTANT  1
  RECHARGE TIMEARRAYSERIES RchArraySeries_1
  RchMult
    INTERNAL  FACTOR  1.0
  0.0  0.0  0.0  0.0  0.0  0.0  0.0  0.0  0.0  0.0
  0.0  1.0  1.0  0.5  0.5  0.0  0.0  0.0  0.0  0.0
  0.0  1.0  1.0  1.0  1.0  0.5  0.0  0.0  0.0  0.0
  0.0  1.0  1.0  1.0  1.0  1.0  0.5  0.0  0.0  0.0
  0.0  0.2  1.0  1.0  1.0  1.0  1.0  0.5  0.2  0.0
  0.0  0.0  0.5  1.0  1.0  1.0  1.0  0.5  0.0  0.0
  0.0  0.0  0.0  0.2  0.2  0.2  0.2  0.0  0.0  0.0
  0.0  0.0  0.0  0.0  0.0  0.0  0.0  0.0  0.0  0.0
  0.0  0.0  0.0  0.0  0.0  0.0  0.0  0.0  0.0  0.0
  0.0  0.0  0.0  0.0  0.0  0.0  0.0  0.0  0.0  0.0
END PERIOD
\end{lstlisting}

Contents of file ``rch\_time\_array\_series.tas'':

\begin{lstlisting}[style=inputfile]
BEGIN ATTRIBUTES
  NAME RchArraySeries_1
  METHOD  LINEAR
END ATTRIBUTES

BEGIN TIME 0.0
  CONSTANT  0.0033
END TIME

BEGIN TIME 91.0
  CONSTANT  0.0035
END TIME

BEGIN TIME 183.0
  CONSTANT  0.0037
END TIME

BEGIN TIME 274.0
  CONSTANT  0.0039
END TIME

BEGIN TIME 365.0
  CONSTANT  0.0035
END TIME
\end{lstlisting}