# On the Need for a General REST-Security Framework
## 6 Towards a General REST-Security Framework
### REST Message Authentication (REMA)
#### 6.2.2 REST Message Signature Generation  
Algorithm 1 defines a general method for ensuring the authenticity and integrity of REST messages by generating a digital signature over the body and security-vital header entries as defined above. Note, that error conditions are not made explicit for readability reasons. Each error will cancel the signature generation process with an according error message.  
Figure 9: General REST message authentication and its instantiation to concrete REST-ful protocolsAs input, the signature generation algorithm requires a REST message \(r\), a signature generation key \(k\) and a description \(desc\). The latter parameter contains application-specific headers, which are to be appended to \(\tilde{h}\). After obtaining the body \(b\) and the header \(h\) from the message \(r\), the function in line 3 checks by means of the REMA policy that all required header entries are included in \(h\) and if so, constructs \(\tilde{h}\) out of them. Then eventually specified additional headers in \(desc\) are appended to \(\tilde{h}\). In order to avoid replay attacks, the signature generation algorithm creates of a fresh time-variant parameter \(tvp\). This parameter is the first element to be assigned to the \(tbs\) variable, which is gradually filled with the data to be signed. These two steps must not be omitted even when a concrete instantiation of this scheme already includes a time-variant parameter in \(\tilde{h}\), since between message generation and signature generation might exist a considerable time spread. All headers contained in \(\tilde{h}\) are normalized and concatenated to \(tbs\). In order to tie the resource representation \(b\) to \(\tilde{h}\) inducing the integrity of the conjunction of security-relevant header entries and body, it needs to be appended to \(tbs\) as well. The resource representation \(b\) is therefore hashed by a cryptographic hash function and the resulting hash value is attached to \(tbs\). Note, that in case a message does have an empty resource representation, a hash of an empty body is computed and added to \(tbs\). The next statement signs the crafted \(tbs\) with a signature generation key \(k\). Algorithm 1 outputs the generated signature value \(sv\) and the time-variant parameter \(tvp\).  
```
0: REST message \(r\), description \(desc\) of the application-specific header entries to be signed, signature generation key \(k\)
0: Signature value \(sv\), time-variant parameter \(tvp\)
1:\(b\gets getBody(r)\)
2:\(h\gets getHeader(r)\)
3:\(\tilde{h}\gets getTbsHeaders(h)\)
4:\(\tilde{h}\leftarrow\tilde{h}\|getTbsHeaders(h,desc)\)
5:\(tvp\gets generateTimeVariantParameter()\)
6:\(tbs\gets tvp\)
7:\(i\gets 0\)
8:while\(i<|\tilde{h}|\)do
9:\(tbs\gets tbs\|delimiter\|normalize(\tilde{h}_{i})\)
10:\(i\gets i+1\)
11:endwhile
12:\(tbs\gets tbs\|delimiter\|hash(b)\)
13:\(sv\gets sign(k,tbs)\)
```  
**Algorithm 1** Representational state transfer (REST) message signature generation [28].  
With these two outputs, an authentication control data element \(m_{cpa}\in M_{cp}\) can be generated, containing the signature algorithm name \(sig\), the hash algorithm name \(hash\), a key identifier \(kid\), the time-variant parameter \(tvp\), the signature value \(sv\) and the presence of additional header entries given by \(desc\) in the specified order. This control data element \(m_{cpa}\) needs ultimately to be embedded into the respective message \(r\). Since resource representations can vary, \(m_{cpa}\) must be integrated into the header \(h\) of the message \(r\) in order to remain data format independent.