The pair of SafetyProviderID and SafetyBaseID is used to check the authenticity of the ResponseSPDU by the SafetyConsumer. SafetyProviderID and SafetyBaseID are usually assigned during engineering or during commissioning. It is in the responsibility of the end user or OEM to assign unique SafetyProviderID to individual SafetyProviders whenever this is reasonable possible. For instance, a machine builder should assign unique SafetyProviderIDs within a single machine.

As the effort for the administration of unique IDs will reach its limits when the system becomes large, OPC UA Safety uses the SafetyBaseID for cases where guaranteeing unique IDs is not possible.

An SafetyBaseID is a universal unique identifier version4 (UUIDv4, also called globally unique identifier (GUID)), as described in https://tools.ietf.org/html/rfc4122. Basically, it is a 128-bit number where more than 96 bits were chosen randomly. The probability that two randomly generated UUIDs are identical, is extremely low (2-96 < 10-28), and can therefore be neglected, even when considering applications with a safety integrity level of 4.

It is not necessary to generate an individual UUID for all SafetyProviders. If two SafetyProviders can be discriminated by their SafetyProviderIDs, they may share the same SafetyBaseID. For instance, a machine builder might generate a SafetyBaseID for each instance of a machine, which is re-used for all SafetyProviders within a machine.

When implementing or using a generator for the UUIDs, it has to be ensured that each possible value is generated with equal probability (discrete uniform distribution), and pair wisely independent from each other. When a pseudo random number generator (PNRG) is used, it is ‘seeded’ with a random source having enough collision entropy (e.g. seeds of at least 128 bits that are uniformly distributed, too; and all seeds being pair wisely independent from each other).

Most commercial systems offer random number generators for applications within a cryptographic context. These applications pose even harder requirements on the quality of random numbers than the ones mentioned above. Hence, cryptographically strong random number generators are considered to be applicable to OPC UA Safety as well. See References [2]-[5] for detailed information.

Table 30shows implementations of cryptographically strong random number-generators that can be used to calculate the random part of the UUIDv4:

Table 30 – Examples for cryptographically strong random number generators.

Environment	Function
Microsoft® Windows® Operating Systems	BCryptGenRandom found in Bcrypt.dll
Unix®-like OS (e.g. Linux® / FreeBSD® / Solaris®)	Read from the file:/dev/urandom/
.NET®	RandomNumberGeneratorfrom System.Security.Cryptography
JavaScript®	Crypto.getRandomValues()
Java®	java.security.SecureRandom
Python®	os.urandom(size)

While being evaluated from a security point of view, probably none of these implementations has been validated with safety kept in mind. Therefore, there is a remaining risk that these implementations are subject to systematic implementation errors which might decrease the effectiveness of these random numbers. To overcome this problem, the output of the random number generator is not used directly, but a SHA256-hash is calculated over (1) the generators output, (2) a timestamp (wall-clock-time or persistent logical clock) and (3) a unique domain name. Any bits of the SHA256-hash can then be used to construct the random parts of the UUIDv4.

[RQ11.1] The parameters SafetyBaseID and SafetyProviderID shall be stored in a nonvolatile way (i.e. persistent).