Data Privacy & Security

Data protection deals in particular with the issue of self-determination with personal data. The General Data Protection Regulation (GDPR/DSGVO) also requires the withdrawal of rights granted to third parties.

With UNITED-PAGES, the owner of the data determines (by choosing an email address) the PROVIDER where his data will be stored and can at any time change in detail who has read or write rights other than him. Current data can thus be read by authorized requester always when required and do not need to be permanently stored elsewhere.

Data security includes techniques that ensure data protection, i.e. how the integrity of the data is secured, how the owner determines access rights and how a requester is authenticated and authorized to access.

Data security is typically implemented using encryption. Asymmetric encryption is a sophisticated way to avoid a complicated exchange of symmetric keys, but in contrast to symmetric encryption it is a time-consuming task and not suitable for a huge amount of data. Hybrid-encryption combines the advantages of asymmetric and symmetric encryption (e.g. in PGP(pretty good privacy) an automatically generated symmetric session key is encrypted with an asymmetric key and the ‘payload’ (message) is encrypted with the symmetric session key).

UNITED-PAGES uses the symmetric encryption of https to protect the request-, response-body and Basic-Authentication-Header. A (https-protected) Authentication-Header may contain a (unencrypted) password within the webservice-request. The password itself can be exchanged beforehand using asymmetric encryption. The asymmetric keys that are used for en-/decryption are stored in pky-UNITs, therefore the procedure that will be described below can be denoted ‘inherent’ i.e. no external system is required.

• Integrity
  The owner’s email address can be derived from the URL/URI of a UNIT, thus ensuring the integrity of the data
  
  
• Authentication
  All requests (GET,PUT, POST, DELETE) can use the HTTP-Basic-Authentication-Header to specify username and password.
  
  If username is an email-address, password must either be a SESSION-PIN or MASTER-PIN.
  
  If the requester is registered with the PROVIDER of the requested WEBSERVER, he can use his MASTER-PIN as password (and his registered email-address as username). The MASTER-PIN belongs to the settings of an ACCOUNT and is usually maintained via a PORTAL. The MASTER-PIN has to be handled carefully. It is not mandatory that the MASTER-PIN is identically with the user's password of the PORTAL. It is in the scope of APPLICATIONs that perform resp. requests how the MASTER-PIN is configured e.g. entered manually for every APPLICATION or using a password-manager.
  
  If the requester (e.g. chris.cons@c_online.com) is not registered with the PROVIDER of the requested WEBSERVER(e.g. pmail.com), he can use a SESSION-PIN as password. The SESSION-PIN can be requested beforehand via a GET-request of a pin-UNIT (that contains the SESSION-PIN) at the requested WEBSERVER
  GET https://www.pmail.com/unit/pin/chris.cons/c_online.com
  RETURN: { "_cpin":"D9Kl4nNmK..." }
  Since the requester is unknown at the requested WEBSERVER and therefore no authentication was possible the (generated) SESSION-PIN is returned encrypted in the response-variable _cpin. The encryption is done with the public-key of the requester, that can be obtained by the requested WEBSERVER by a GET-request to the resp. pki-UNIT from the requester’s WEBSERVER.
  GET https://www.c_online.com/unit/pki/chris.cons/.c_online.com
  RETURN: { "publickey":"-----BEGIN PUBLIC KEY-----\nMIICIjAN...wEAAQ==\n-----END PUBLIC KEY-----" }
  
  Only the ‘real’ owner of the email-address (e.g. chris.cons@c_online.com) who knows the private-key can decrypt the response. The (decrypted) SESSION-PIN can be used until expiration (default: 5 Minutes) for any subsequent requests to the requested WEBSERVER (e.g. pmail.com). Since asymmetric encryption is computationally intensive, not a requested UNIT is encrypted, but only the (temporarily valid) SESSION-PIN. It is in the scope of APPLICATIONs that perform resp. requests how the Private-Key is configured (e.g. a GET-request of the resp. pky-UNIT on the own WEBSERVER using the MASTER-PIN for authentication returns additionally the privatekey variable).
  
  The procedure is shown in detail below and could also be used to exchange a (encrypted) JWT instead of a (encrypted) SESSION-PIN. The special feature is the inherent possibility to retrieve the Public-Key of a CONSUMER that is registered with any PROVIDER.
  
  
• Authorization
  An authenticated requester can create its own new UNITs (PUT), delete its own UNITs (DELETE) and query(GET) or change(PUT) each variable from its own UNITs.
  
  The owner of a UNIT can tag individual variables of it's UNITs for non-public access and can even grant access rights to requesters who are not registered/unknown with his own PROVIDER. One of the most important functionalities of UNITED-PAGES is, that this is possible with inherent means only. As shown, authentication is based on the fact that a requester’s private-key can be queried using the email address from the Authentication-Header. Authorization is based on the configuration of email addresses whose (authenticated) owners also receive access rights to all variables marked as non-public. Corresponding email address lists can be configured as lst-UNITs and can be assigned individually or to several own UNITs.
  
  Without authentication, a requester (regardless of whether he is registered with any PROVIDER) can read (GET) public non-tagged variables of foreign UNITs. A special case is possible with the unit-specific UNIT-PIN, which the owner of a UNIT can assign. If a requester has the UNIT-PIN, he can read (GET) and even write (PUT) to all variables (except the UNIT-PIN itself). The UNIT-PIN must be specified as password in the Authentication-Header like the MASTER-PIN and SESSION-PIN. Instead of an email-address, the value “_upin” must be used as username. The configuration of a UNIT-PIN by the owner of a UNIT is optional and in particular the distribution must be done outside of UNITED-PAGES on secure channels.

if ( <Authentication-username> == '_upin' ) {
	if ( <Authentication-password> == <UNIT-PIN of requested UNIT> )
		return true;
	else
		return false;
}

if ( <Authentication-username> != <any email-address> )
	return false;

if ( <Authentication-username> == <email-address of any user that is registered on this Webserver> ) {
	if ( <Authentication-password> == <MASTER-PIN of email-address> or
		 <Authentication-password> == <SESSION-PIN of email-address> )
		return true;
	else
		return false;
}
	
if ( <Authentication-password> == <SESSION-PIN of email-address> )
	return true;
else
	return false;