[opendtv] Microsoft and the broadcast flag

  • From: "Manfredi, Albert E" <albert.e.manfredi@xxxxxxxxxx>
  • To: <opendtv@xxxxxxxxxxxxx>
  • Date: Tue, 8 Jul 2008 18:26:59 -0400

I always recommend going to original source documentation. Going to the
Microsft site and doing a simple search tells it how it is.



This paper provides information about Protected Broadcast Driver
Architecture for the Microsoft Windows family of operating systems. It
provides guidelines for audio video tuner devices to build devices that
can deliver protected broadcast content to a digital rights management
(DRM)-approved recording application in a dynamic way.

This information applies for Microsoft Windows Vista. Future versions of
this preview information will be provided in the Windows Driver Kit at


[ ... ]

1 Introduction

The current Broadcast Driver Architecture (BDA) interfaces are used to
transfer clear text audio and visual content from a tuner to a recording
application in digital form. Protected BDA defines extensions to these
interfaces to allow tuners to securely transfer dynamic broadcast
content to Microsoft(r) Windows(r) Media digital rights management
(WMDRM)-authorized playback, capture, or interactive Media Center-style
applications. The goals of Protected BDA design include limiting the
impact on cost to the tuner as much as possible, while still allowing
the tuner to address a wide range of industry requirements for protected

These extensions work by settings up a secure channel between the
hardware tuner device and the WMDRM system. In turn, the WMDRM system
releases content to recording, playback, and other authorized
applications. WMDRM is viewed as the most robust component within the
system to control conditional-access content, by holding onto and
protecting keys through a variety of ever-growing technologies. This
allows the Protected BDA device to trust the system to which it is
delivering content by getting trust directly from WMDRM. WMDRM then
enforces proper downstream behavior by entrusting components with access
to the data through a revocation and a renewability system.

The device uses standard cryptographic protocols to check for an
authorized WMDRM system and to set up a secure data channel,
specifically, asymmetric RSA public/private key operations at
initialization and AES symmetric counter-mode operations during run time
to securely move content. Next, the Protected BDA interfaces are
designed to efficiently support the dynamic nature of broadcast content.

This document covers, in detail, the implementation details for a tuner
device to solve these problems in a common way.

2 FCC Broadcast Flag

A tuner that correctly implements Protected BDA natively supports the
marked content rules for the Federal Communications Commission (FCC)
broadcast flag. By properly performing the certificate steps at
initialization to set up a connection to the Microsoft WMDRM system, the
Protected BDA tuner is using an FCC-approved output mechanism. The tuner
must inform the WMDRM-approved capturing application that it is
delivering unscreened Advanced TV Systems Committee (ATSC) content or
that it has screened the content (in which case the tuner provides the
marked content flag). If the tuner supplies unscreened ATSC content,
WMDRM enforces the approved capture application to screen the incoming
content. No matter where the detection is done, WMDRM protects the
broadcast flag marked content.

[ ... ]

This Microsoft paper seems to agree with what Microsoft explained to the
TV Technology reporter.

Bottom line is, Microsoft has taken it upon itself to (a) decide that
the BF still applies, (b) interpret what the FCC thinks the "broadcast
flag" means, and (c) decide which devices installed in a given PC are
worthy of accepting BF-coded content. Obviously, I've no way of knowing
how a particular PC was built, what keys had been supplied to its
various components, etc.

My earlier post, where I listed a possible way of coding a TV recording
device to avoid stepping on the toes of consumers or content owners,
would apply also to this PC example.

All that said, what Microsft is doing is perfectly legal, so they are
not really who we should be most peeved at.

You can UNSUBSCRIBE from the OpenDTV list in two ways:

- Using the UNSUBSCRIBE command in your user configuration settings at 

- By sending a message to: opendtv-request@xxxxxxxxxxxxx with the word 
unsubscribe in the subject line.

Other related posts: