Demystifying Cryptography in ServiceNow: A Comprehensive Guide to Secure Data Transmission

This article is the 1st in a series of posts that aim to demystify the complex world of cryptography within ServiceNow. In this installment, we dive into the foundational topics of URL encoding, base64 encoding, hashing, symmetric and asymmetric encryption, hybrid encryption, and digital signatures.

These cryptographic principles are essential for understanding the more advanced topics we will explore in subsequent articles, including a detailed look at SAML 2.0 in our second piece. This series aims to provide both newcomers and seasoned developers with a thorough understanding of cryptographic techniques used in ServiceNow.

Now, let’s begin our journey by exploring the fundamental concept of URL encoding.

Understanding URL Encoding

URL encoding is important in web development because it ensures that special characters in URLs are properly handled for internet transmission. Let’s break down the basics of URL encoding and its importance.

Why URL Encoding is Necessary?

When you construct a URL, you can’t include certain characters directly, such as spaces, question marks (?), and equals signs (=). These characters have different purposes within the URL syntax. To include them in the URL’s parameters and values, you need to encode them into a specific format.

The URL Encoding Process

URL encoding changes special characters into a text-based format so URLs can be safely sent and understood by web servers and browsers.


Consider the following text that we want to include as part of a URL: “Hello World?“.  Through the URL encoding algorithm, this text is transformed into the following encoded format: “Hello%20World%3F
Here, the space is encoded as “%20“, and the question mark is encoded as “%3F“.


Not Encryption, but Transformation:

It’s important to understand that URL encoding is not a form of encryption. Its purpose is to convert text into a format that can be safely included in a URL, ensuring proper transmission rather than hiding the data.

Usage in ServiceNow

  1. REST API Requests: ServiceNow REST APIs often need URL encoding to handle special characters in request parameters, query strings, or resource identifiers (specific records, tables, or endpoints within the ServiceNow instance). URL encoding ensures the data in API requests is correctly formatted and interpreted by the ServiceNow instance.
  2. Integration URLs: URLs used in ServiceNow integrations, such as inbound or outbound web service integrations, may require URL encoding to manage special characters in endpoint URLs or request payloads. This encoding helps ensure smooth data exchange between ServiceNow and external systems.
  3. UI Actions and Script URLs: When setting up UI actions or script URLs in ServiceNow, URL encoding may be necessary to encode dynamic parameters or values containing special characters. This ensures that dynamically generated URLs in UI actions or scripts are correctly formatted and interpreted by the platform.

After understanding the importance of URL encoding, let’s shift our focus to another essential encoding technique utilized in ServiceNow: Base64 encoding.

Base64 Encoding in ServiceNow

Why Base64 Encoding is Necessary?

In ServiceNow, Base64 encoding addresses the need to convert binary data, such as images, compressed data, or compiled data, into a textual representation. This conversion enables the embedding of binary data into various text-based formats, such as HTML, CSS, or XML files, facilitating seamless integration and transmission across different systems and platforms.

The Base64 Encoding Process

Base64 encoding converts binary data into a text-based format using a specific encoding algorithm. This process transforms binary data into a set of ASCII characters, allowing you to safely transmit it over protocols that only support text data. Conversely, Base64 decoding reverses this process, converting the encoded text back into its original binary form.


Imagine a scenario where a ServiceNow application needs to transmit binary data, such as an image file, over an HTTP request. Before transmission, the binary data undergoes Base64 encoding to convert it into a text-based representation. This encoded data can then be included in the HTTP request payload. Upon receiving the request, the ServiceNow instance decodes the Base64 encoded data to reconstruct the original binary file.

Base64 Encoding & Decoding Scripts

// Base64 Encoding Example
var binaryData = new GlideStringUtil();
var base64EncodedData = binaryData.base64Encode('Hello World'); // Base64 encode data'Base64 Encoded Data: ' + base64EncodedData); // Log Base64 encoded data// Base64 Decoding Example
var base64EncodedData = 'SGVsbG8gV29ybGQ/'; // Base64 encoded data
var binaryData = GlideStringUtil.base64Decode(base64EncodedData); // Decode Base64 data'Decoded Binary Data: ' + binaryData); // Log decoded binary data

Usage in ServiceNow

  1. Attachment Handling: When you upload file attachments to a ServiceNow record, ServiceNow converts the files to Base64 format before storing or sending them using REST. When you download these attachments, ServiceNow changes the Base64 data back to the original file format.
  2. Integration Payloads: In integrations between ServiceNow and external systems, you use Base64 encoding to send binary data, like images or documents, over HTTP requests or other communication methods. This ensures smooth data exchange between ServiceNow and other platforms.

Also, you often send binary data through HTTP POST requests, especially in authentication systems like SAML or OpenID Connect. In these cases, you usually convert the binary data to Base64 format before sending it via HTTP POST. If you use the Base64-encoded data in a URL, you also need to URL encode it. This process ensures that binary data is securely and reliably transmitted over text-based protocols.

Now that we’ve explored the essential encoding techniques used in ServiceNow, let’s delve into the world of hashing, a fundamental cryptographic process that ensures data integrity and security.

Hashing in Cryptography

In cryptography, hashing stands as a fundamental concept, forming the foundation of many security protocols and mechanisms. At its core, a cryptographic hashing function transforms any input data into a fixed-size text representation known as a hash or digest using hashing algorithms like SHA-256/512 or MD5. This is an irreversible process and it ensures data integrity and uniqueness.

Applications of Hashing

  1. Password Security: When storing passwords in a database, systems use hashing algorithms like SHA-256 or SHA-512 to hash the password along with any optional salt (a prefix or a postfix). To authenticate logins, the system hashes the password entered by the user using the same algorithm and compares it with the hashed password stored in the database. This ensures passwords are securely stored and enables secure logins.
  2. Data Integrity Verification: You can also hash files to generate a digest. The hashed value or digest of the file will not change unless someone tampers with the file. This helps verify data integrity during transmission.
  3. Message Authentication: Hashing ensures that messages are authentic and have maintained their integrity during transmission. In authentication systems, hashes are used to verify that the message has not been changed or tampered with.

Hashing in ServiceNow

ServiceNow prioritizes data security and integrity by using hashing algorithms like SHA-256 and SHA-512 to strengthen authentication and verify data integrity.

Hashing is also important in protocols like SAML 2.0 for checking data integrity and message authentication. We will discuss this more in the next article on SAML 2.0.

Unlocking Encryption: Key-Based Symmetric and Asymmetric Techniques

The primary goal of encryption is to safeguard confidentiality, ensuring that only intended recipients can understand the transmitted data.

In this article, we will delve into key-based encryption—a method extensively utilized in contemporary digital environments, including by platforms like ServiceNow.

We will explore two predominant types of encryption: symmetric and asymmetric, each with its unique advantages and challenges. Due to these characteristics, the industry has developed hybrid encryption, which combines the strengths of both symmetric and asymmetric methods. By understanding these three encryption types, we can better appreciate why ServiceNow adopts them and how they can help address challenges that may arise when dealing with this topic within the platform.

Let’s now explore each of them.

Symmetric Encryption: A Real-Time Approach

In symmetric encryption, you use a single key for both encrypting and decrypting data. This method is fast, uses less CPU power, and keeps the encrypted text (cipher) the same size as the original text. Such efficiency makes symmetric encryption best for applications where real-time encryption and decryption are crucial, such as secure communication channels (e.g., VPNs) or data streaming services (e.g., Netflix).

However, symmetric encryption presents a significant challenge: securely sharing the encryption key between the sender and the recipient. Without a secure mechanism for key distribution, the integrity of encrypted communication may be compromised. This necessity highlights the importance of encryption protocols and the ongoing need for robust security measures, including key management systems and secure channels for key exchange.

One commonly used algorithm in symmetric encryption is the Advanced Encryption Standard (AES). AES allows for various key lengths, such as AES-128, AES-192, and AES-256, with ServiceNow predominantly using AES-128 due to its balance between security and efficiency

Strengths of Symmetric Encryption:

  • Faster processing compared to asymmetric encryption.
  • Maintains the size of the encrypted text equal to the original plaintext.
  • Ideal for real-time encryption and decryption scenarios.

Weaknesses of Symmetric Encryption:

  • Requires secure distribution of encryption keys.
  • Vulnerable to key interception or compromise.
  • Limited scalability for large-scale encryption operations.

Example: Symmetric Encryption

In the context of symmetric encryption, let’s consider a scenario involving two users: Alice (the sender) and Bob (the recipient). They communicate over the internet, represented by a cloud icon, and exchange sensitive information securely using symmetric encryption.


Asymmetric Encryption: Securing Communications with Keys

To address the limitations of symmetric encryption, especially the challenge of securely sharing the secret key, cryptographers developed asymmetric encryption, also known as public-key encryption. This method uses two keys for each participant: a private key and a public key. Asymmetric encryption enhances security by allowing secure communication without the need for exchanging secret keys beforehand.

In asymmetric encryption, each participant generates a unique pair of keys: a private key and a public key. The private key is kept secure by the owner and never shared, acting as a digital signature to confirm the owner’s identity and authenticity. The public key, on the other hand, is shared freely, allowing others to send secure communications without compromising security.

The RSA algorithm is the most widely used method in asymmetric encryption. It involves a private key and a public key. Data encrypted with the public key can only be decrypted with the corresponding private key, ensuring confidentiality and security. Likewise, data signed with the private key can be verified with the public key, guaranteeing authenticity and integrity.

Now, let’s illustrate how asymmetric encryption works in practice with a scenario involving Alice and Bob:

Example: Secure Email Communication

Alice, a business executive, needs to send a confidential email containing financial reports to Bob, her colleague. To ensure the privacy and integrity of the email contents, both Alice and Bob utilize asymmetric encryption:

  • Key Generation: Both Alice and Bob generate their own pairs of asymmetric encryption keys: a Private key and a corresponding Public key. Each individual keeps their Private key securely stored and never shares it with anyone, while freely distributing their Public key to others.
  • Encryption: Before sending the email, Alice encrypts the contents using Bob’s Public key. This process transforms the plaintext email into ciphertext, ensuring that only Bob, with his corresponding Private key, can decrypt and read the message. The encrypted email is then sent to Bob via the email service provider.
  • Reception by Bob: Upon receiving the encrypted email, Bob uses his Private key to decrypt the contents. Only Bob’s Private key, known only to him, can successfully decrypt the ciphertext, revealing the original plaintext email.
  • Response: If Bob needs to respond to Alice’s email, he can encrypt his reply using Alice’s Public key. This ensures that only Alice, with her corresponding Private key, can decrypt and read the message, maintaining the security of their communication.

By leveraging asymmetric encryption with RSA keys, Alice and Bob can securely exchange sensitive information via email, confident in the confidentiality, authenticity, and integrity of their communication.

In practical implementations, the distribution and verification of public keys are facilitated by digital certificates issued by trusted Certificate Authorities (CAs). These certificates, conforming to the X.509 standard, bind public keys to identities, providing a reliable means of authentication and trust in the digital world.

Strengths of Asymmetric Encryption:

  • Private key is never shared, enhancing security.
  • Facilitates secure digital signatures and key exchange protocols.
  • Enables secure communication over insecure channels without pre-shared keys.

Weaknesses of Asymmetric Encryption:

  • Increased computational overhead compared to symmetric encryption.
  • Larger key sizes lead to larger ciphertexts and slower processing speeds.
  • Key management and distribution can pose logistical challenges in large-scale deployments.

Through asymmetric encryption with individual pairs of asymmetric encryption keys, Alice and Bob can securely exchange sensitive information via email, protecting the confidentiality, authenticity, and integrity of their email correspondence.

Hybrid Encryption: Combining the Best of Both Worlds

While symmetric encryption excels in real-time encryption and decryption scenarios, and asymmetric encryption provides secure key exchange, both methods have their limitations. Symmetric encryption requires a secure channel for key distribution, while asymmetric encryption introduces computational overhead. Hybrid encryption combines the strengths of both approaches, maximizing security in data transmission.

In hybrid encryption, symmetric encryption encrypts the actual data, while asymmetric encryption securely exchanges the symmetric key. This approach minimizes computational overhead and ensures secure key distribution, making it ideal for applications where both efficiency and security are important.

Let’s delve deeper into how hybrid encryption works through an example of secure email communication between Alice and Bob:

Example: Secure Email Communication

Alice, needing to send a large financial report to Bob, initiates the hybrid encryption process:

  • Key Generation: Alice generates a random secret key and uses symmetric encryption (e.g., AES 256) to encrypt the email contents, including any attachments.
  • Encryption of Secret Key: Alice encrypts the random secret key using Bob’s public key, ensuring that only Bob can decrypt it.
  • Secure Transfer: Alice sends the AES-encrypted data and the asymmetrically encrypted secret key to Bob through the email service provider.
  • Reception by Bob: Upon receiving the encrypted data and secret key, Bob decrypts the asymmetrically encrypted key using his private key, obtaining the original secret key. Finally, Bob uses the decrypted secret key to decrypt the AES-encrypted data, recovering the plaintext email and any attachments.

Applications automatically handle encryption and decryption using libraries. For example, when generating a SAML request, ServiceNow generates encrypted data and key information using packages, stores them in XML format, and sends them using HTTP post. ServiceNow also base64 encodes these encrypted pieces to keep the data intact during transmission.

Hybrid encryption combines the strengths of both symmetric and asymmetric methods. This approach ensures secure and efficient data exchange, providing strong protection for data as it travels.

Digital Signatures: Ensuring Data Integrity and Authenticity

In addition to encryption, digital signatures play a crucial role in securing data transmission, providing integrity and authentication. While encryption safeguards the confidentiality of data, digital signatures verify the origin and integrity of the message.

Let’s delve into how digital signatures work and how they complement encryption:

Utilizing Hashing Algorithms: Digital signatures leverage hashing algorithms to condense messages into smaller, fixed-size representations, ensuring efficient processing. These algorithms generate a unique fingerprint or digest of the original message, preserving its integrity.

Signature Generation: Suppose Alice intends to send a message to Bob. Alice first generates the message and then applies a hashing algorithm to produce a digest of the message. Next, she encrypts this digest using her private key, creating the signature. This signature serves as proof of authenticity and integrity for the message.

Signature Verification: Upon receiving the message and signature, Bob employs Alice’s public key to decrypt the signature, revealing the original digest. Independently, Bob calculates a hash of the received message. If the calculated hash matches the decrypted digest, two critical aspects are verified:

  • Integrity: Any alteration to the message would result in a different hash, ensuring that the message remains unchanged since Alice signed it.
  • Authentication: Since only Alice’s private key could have generated the signature, decrypting it with Alice’s public key confirms its authenticity. This authentication mechanism proves that Alice is the true sender of the message.

Application of Signatures: While we often associate signatures with messages, they extend beyond text-based communication. Signatures can authenticate various data forms, such as certificates, software, emails, and more. The essence of signatures lies in providing both integrity and authentication, irrespective of the data type.

Let’s illustrate the digital signature process using Alice and Bob:

Example: Signing a Data Message

Imagine Alice needs to sign a critical document or data message and send it to Bob securely. Here’s how digital signatures come into play:

  • Message Creation: Alice prepares the document or data message that needs to be signed. It could be any digital content, such as a contract, a software update, or an important report.
  • Signature Generation by Alice: Before sending the data message, Alice computes a hash (digest) of the message using a hashing algorithm like SHA256. This hash serves as a unique representation of the content. Alice then encrypts this hash using her private key, generating the digital signature.
  • Sending the Signed Message: Alice sends the data message along with the digital signature to Bob. The message contains both the original content and the attached signature.
  • Verification by Bob: Upon receiving the data message, Bob extracts the message and the attached digital signature. Using Alice’s public key, which he previously obtained or can access from a trusted source, Bob decrypts the digital signature, obtaining the hash of the original message.
  • Hash Calculation by Bob: Independently, Bob calculates the hash of the received message using the same hashing algorithm (SHA256). This calculation results in a hash value.
  • Comparing Hashes: Bob compares the hash value obtained from his calculation with the decrypted hash obtained from Alice’s digital signature. If the two hash values match, Bob can be confident that the message has not been altered since Alice signed it. This verifies the integrity of the data message.
  • Authentication: Additionally, since only Alice’s private key could have produced the digital signature that Bob successfully decrypted with Alice’s public key, Bob can authenticate that the message indeed originated from Alice.

By using digital signatures in data transmission, Alice and Bob can ensure their communication is both genuine and intact, adding more security beyond encryption.

This example shows how digital signatures make data exchange safer by keeping messages unchanged and verifying the sender’s identity.

While this example only uses digital signatures without encryption, combining both techniques often boosts security. For instance, in SAML scenarios, Alice can first sign the data with her private key, then encrypt it with Bob’s public key before sending it. Bob would then decrypt the message with his private key and verify its origin with Alice’s public key.

This hybrid method, mixing digital signatures and encryption, fully protects sensitive data during transmission, ensuring both integrity and authenticity. We’ll explore these scenarios more in our next article on SAML 2.0.


In this article, we explored the essential cryptographic technologies necessary for securing applications within ServiceNow. Understanding these principles sets the stage for our next discussion on SAML 2.0, where we’ll dive deeper into how these cryptographic measures are applied in implementing secure Single Sign-On (SSO) solutions. Stay tuned for more advanced topics that will further enhance your security posture in ServiceNow.

Date Posted:

June 10, 2024

Share This:

Leave A Comment




Fresh Content
Direct to Your Inbox

Just add your email and hit subscribe to stay informed.