How to Secure SAS-CBSD Communications

This guide explains how to implement secure communications between CBSD and SAS as required by WINNF-TS-0016, WINNF-TS-0065 (Communications Security), and WINNF-TS-0022 (PKI Policy).

Overview

All SAS-CBSD communications must use HTTPS with mutual authentication. This prevents rogue devices, man-in-the-middle attacks, and ensures data integrity/confidentiality.

Key requirements:

• TLS 1.2 or higher (TLS 1.3 recommended)
• Mutual certificate authentication (client and server certificates)
• Certificates issued under the WInnForum CBRS PKI root hierarchy
• Proper certificate validation (chain, revocation, hostname)

Prerequisites

• Obtain a valid CBSD device certificate from an approved Certificate Authority (CA) in the WInnForum PKI trust chain
• Have the SAS server certificate or trust the root CA
• Configure your HTTP client library to support mutual TLS

Step 1: Obtain Certificates

• CBSD Client Certificate:
  • Issued to your device (contains FCC ID and serial number in subject)
  • Private key securely stored on device (never exposed)
• Trust Store:
  • Include WInnForum root and intermediate CAs
  • Optionally include SAS-specific server certificates

Tip: Many SAS providers (including Key Bridge) supply tools or portals to generate/request device certificates.

Step 2: Configure HTTPS Client for Mutual Authentication

Example configurations for common environments:

Python (requests library)

import requests

session = requests.Session()
session.cert = ('cbsd_client_cert.pem', 'cbsd_private_key.pem')

# Optional: Custom trust store
session.verify = 'winnforum_root_ca.pem'

# Use session for all SAS requests
response = session.post('https://sas.example.com/v1.2/registration', json=payload)

Curl (for testing)

curl -X POST https://sas.example.com/v1.2/registration \
  --cert cbsd_client_cert.pem \
  --key cbsd_private_key.pem \
  --cacert winnforum_root_ca.pem \
  -H "Content-Type: application/json" \
  -d @request.json

Step 3: Validate Server Certificate

Always verify:

• Server hostname matches certificate CN/SAN
• Certificate chain traces to trusted WInnForum root
• Certificate not revoked (OCSP or CRL checking if supported)
• Valid dates

Tip: Disable hostname verification only for testing — never in production.

Step 4: Test Client Certificate Validity

Use the Key Bridge proprietary health responder to quickly verify your client certificate is trusted:

URL: https://sas.cbrs.keybridgewireless.com/cbsd/api/v1.2/health

This endpoint responds to GET requests only and performs no CBRS protocol processing.

Test Command (curl)

curl -v --cert cbsd_client_cert.pem \
       --key cbsd_private_key.pem \
       --cacert winnforum_root_ca.pem \
       https://sas.cbrs.keybridgewireless.com/cbsd/api/v1.2/health

Expected:

• HTTP 200 OK
• Simple JSON status response

Common Errors:

• 401/403 → Certificate not trusted or invalid
• SSL handshake failure → Wrong key, format, or missing CA

Note: This endpoint cannot be used to test CBRS messaging (POST requests with protocol payloads). It only affirms client certificate validity.

Step 5: Handle Certificate Renewal

• Device certificates typically valid 1-3 years
• Monitor expiration dates
• Renew before expiry to avoid outages
• Re-register may be required after certificate change

Best Practices & Tips

• Store private keys in hardware security module (HSM) or secure enclave if possible
• Use separate certificates per device (not shared)
• Rotate certificates periodically
• Log TLS errors for quick troubleshooting
• Test connectivity with the health endpoint during development and provisioning
• With Key Bridge SAS: We support modern TLS versions and provide detailed connection diagnostics if authentication fails

Common Issues & Troubleshooting

Next Steps

• Validate your setup using the health endpoint
• Integrate certificate management into your device provisioning workflow