Tiêu chuẩn Quốc gia TCVN 11819:2017 Khối truy nhập có điều kiện dùng trong truyền hình kỹ thuật số-Yêu cầu kỹ thuật đối với giao diện chung mở rộng (CI Plus)

TIÊU CHUẨN QUỐC GIA

TCVN 11819:2017

KHỐI TRUY NHẬP CÓ ĐIỀU KIỆN DÙNG TRONG TRUYỀN HÌNH KỸ THUẬT SỐ - YÊU CẦU KỸ THUẬT ĐỐI VỚI GIAO DIỆN CHUNG MỞ RỘNG (CI PLUS)

Conditional access module for digital television - Technical requirements for common interface plus (CI PLUS)

MỤC LỤC

1  Phạm vi áp dụng

2  Tài liệu viện dẫn

3  Định nghĩa, ký hiệu và chữ viết tắt

3.1  Định nghĩa

3.2  Ký hiệu

3.3  Chữ viết tắt

4  Tổng quan hệ thống

4.1  Giới thiệu

4.2  Các thành phần của hệ thống kiểm soát nội dung

4.3  Nguyên tắc hoạt động chung

4.4  Xác thực thiết bị

4.5  Trao đổi mã khóa và mã hóa nội dung

4.6  MMI nâng cao

4.7  Các mở rộng của Cl Plus

5  Tổng quan kiểm soát nội dung

5.1  Kiến trúc

5.2  Tổng quan về hành vi giao diện

5.3  Phân cấp mã khóa

5.4  Triển khai mô-đun

5.5. Giới thiệu phương pháp thu hồi (tham khảo)

5.6. Xáo trộn (Giải xáo trộn) nội dung

5.7. Thực hiện kiểm soát sao chép nội dung

5.8. Các chế độ hoạt động

5.9. Tổng quan xác thực

5.11. Kiểm soát của cha mẹ

5.12. Ghi và phát lại

5.13. Cung cấp SRM

6. Cơ chế xác thực

6.1. Đăng ký và liên kết CICAM

6.2. Giao thức xác thực

6.3. Xác thực lại khi bật nguồn điện

7. Kênh được xác thực an toàn

7.1. Hoạt động Cl SAC

7.2. Định dạng của bản tin SAC

7.3. Truyền các bản tin SAC

7.4. Nhận các bản tin SAC

7.5. Tích hợp SAC vào Cl Plus

8. Các tính toán mã khóa nội dung

8.1. Giao thức làm mới mã khóa kiểm soát nội dung

9. Chi tiết về chứng nhận và PKI

9.1. Giới thiệu

9.2. Kiến trúc quản lý chứng nhận

9.3. Định dạng giấy chứng nhận

9.4. Kiểm tra giấy chứng nhận

10. Ngăn chặn dịch vụ của máy chủ

10.1. Thông báo dịch vụ được Cl Plus bảo vệ

10.2. Tiếp nhận tin cậy

10.3. Chế độ dịch vụ được Cl Plus bảo vệ

10.4. Ngăn chặn dịch vụ

11. Giao diện lệnh

11.1. Tài nguyên thông tin ứng dụng

11.2. Tài nguyên ngôn ngữ và quốc gia của máy chủ

11.3. Tài nguyên kiểm soát nội dung

11.4. Hỗ trợ ứng dụng cụ thể

12. MMI cấp ứng dụng Cl Plus

12.4. Phạm vi

12.2. Hồ Sơ MMI ứng dụng

12.3. Mã hóa nội dung dữ liệu

12.4. Mẫu đồ họa của công cụ

13. Tài nguyên giao diện người - máy của Cl Plus

13.3. Kết hợp các tài nguyên MMI

13.4. Trình đơn CICAM

14. Các phần mở rộng Cl khác

14.2. Phần mở rộng truyền IP tốc độ thấp

14.3. Tải về phần mềm và tài nguyên nâng cấp CAM

14.4. Tài nguyên MMI ứng dụng

14.5. Tài nguyên MMI ứng dụng v2

14.6. Tài nguyên kiểm soát máy chủ DVB

14.7. Hồ sơ nhà điều hành

Phụ lục A (quy định) Bộ tạo số ngẫu nhiên

A.1. Định nghĩa bộ tạo số ngẫu nhiên

Phụ lục B (quy định) Giao thức ID thiết bị

B.1. Bản quy định kỹ thuật ID thiết bị

Phụ lục C (quy định) Các thuật toán kiểm tra tổng

C.1. Các thuật toán kiểm tra tổng

Phụ lục D (quy định) Các khả năng SD và HD

D.1. Định nghĩa SD và HD

Phụ lục E (quy định) Kiểm tra các trường hợp sử dụng DVB-CI

E1. Khởi tạo

E.2. CA_PMT rõ ràng

E.3. CA_PMT rõ ràng sang bị xáo trộn /bị xáo trộn sang rõ ràng

E.4. Cập nhật PMT và CA_PMT mới

E.5. MMI tức thời

E.6. Dòng truyền tải đến CICAM

E.7. Trả lời về hồ sơ

E.8. Hoạt động trên một bus dùng chung

E.9. Kích thước APDU tối đa

E.10. Tài nguyên kiểm soát máy chủ

E.11. Trả lời CA-PMT

E.12. Tài nguyên CC và CP

E.13. Các yêu cầu vật lý

E.14. Đối tượng Comms Reply truyền tốc độ thấp

E.15. Mã hóa đối tượng văn bản MMI cấp cao

E.16. Đối tượng dò kênh kiểm soát máy chủ DVB

E.17. Hỗ trợ truy nhập có điều kiện

E.18. Xử lý phiên bản tài nguyên

E.19. Yêu cầu mở phiên

E.20. Cung cấp CA PMT

E.21. Đánh giá của CICAM về các CA_descriptor

E.22. Hành vi đóng phiên hỗ trợ CA

E.23. Các lệnh ca_pmt

E.24. open_session_response

E.25. Mã hóa ký tự

Phụ lục F (quy định) Định nghĩa và xử lý mã lỗi

F.1. Các mã lỗi

Phụ lục G (quy định) Tối ưu PCMCIA

G.1. Kích thước bộ đệm

G.2. Chế độ ngắt

G.3. Xác định khả năng tương thích Cl Plus

Phụ lục H (quy định) Bản quy định kỹ thuật chứng nhận

H.1. Các thông số được trao đổi trong các APDU

Phụ lục I (quy định) Sử dụng PKCS # 1

l.1. Các đóng dấu RSA theo PKCS # 1

Phụ lục J (quy định) Định dạng độ dài thẻ

J.1. Định dạng độ dài thẻ

Phụ lục K (quy định) Bản quy định kỹ thuật điện

K.1. Bản quy định kỹ thuật điện

Phụ lục L (quy định) Tóm tắt tài nguyên

L.1. ID tài nguyên

L.2. Tóm tắt tài nguyên

Phụ lục M (quy định) Định dạng bản tin ứng dụng MHP

M.1. Giới thiệu

M.2. Định dạng bản tin

M.3. Các thành phần bản tin

M.4. Các loại bản tin

M.5. Các loại sự kiện

M.6. Các thành phần datatype_id

M. 7. Ánh xạ MHP API

Phụ lục N (quy định) Hồ sơ truyền hình CICAM

N.1. Thông tin dịch vụ

N.2. Hành vi định hình

Lời nói đầu

TCVN 11819:2017 được xây dựng trên cơ sở tham khảo tiêu chuẩn Cl Plus™ Specification v1.3.2.

TCVN 11819:2017 do Viện Khoa học Kỹ thuật Bưu Điện biên soạn, Bộ Thông tin và Truyền thông đề nghị, Tổng cục Tiêu chuẩn Đo lường Chất lượng thẩm định, Bộ Khoa học và Công nghệ công bố.

KHỐI TRUY NHẬP CÓ ĐIỀU KIỆN DÙNG TRONG TRUYỀN HÌNH KỸ THUẬT SỐ - YÊU CẦU KỸ THUẬT ĐỐI VỚI GIAO DIỆN CHUNG MỞ RỘNG (Cl PLUS)

Conditional Access Module for Digital Television - Technical requirements for Common Interface plus (Cl Plus)

1  Phạm vi áp dụng

Tiêu chuẩn này giải quyết các vấn đề về bảo vệ nội dung sau khi gỡ bỏ bảo vệ truy nhập có điều kiện, đặc biệt tại vị trí nội dung rời khỏi CICAM và trở lại máy chủ. Đây là các vấn đề mà các nhà cung cấp dịch vụ, nhà khai thác CA và chủ sở hữu nội dung luôn quan tâm, lo ngại. Để loại bỏ những lo ngại này, cần phải có một hệ thống kiểm soát nội dung mạnh mẽ và hiệu quả để bảo vệ nội dung tại vị trí này.

Tiêu chuẩn này mô tả một hệ thống bao gồm tất cả các quy tắc để xác thực, tạo khóa và chuyển tiếp thông tin kiểm soát sao chép. Phạm vi của hệ thống này là kết nối từ CICAM đến máy chủ, nó không liên quan đến một hệ thống CA cụ thể hay hệ thống CA mở rộng bên ngoài máy chủ. Phạm vi này không giới hạn ở một loại giao diện cụ thể nào, tuy nhiên hiện tại vẫn phổ biến sử dụng khe cắm PCMCIA, những vấn đề có thể phát sinh từ việc sử dụng giao diện khác chưa được xác định hoặc giải quyết trong tiêu chuẩn này.

Các cơ chế được xác định trong tiêu chuẩn này được gọi là giao diện chung mở rộng hoặc Cl Plus. Tiêu chuẩn này dựa trên và mở rộng từ các tiêu chuẩn Cl hiện có như EN 50221 [7] và TS 101 699 [8].

Để đảm bảo an ninh tối đa trong một môi trường tiềm ẩn nhiều hành động xâm hại hệ thống, tiêu chuẩn này sử dụng một tập hợp các kỹ thuật đã được thiết lập, đã được ngành công nghiệp chấp nhận và xác nhận, bao gồm cả mã hóa và xác thực thiết bị và bản tin.

Việc xác thực giữa CICAM và máy chủ sẽ xác nhận với CICAM rằng nó đang hoạt động với một máy chủ hợp pháp. Điều này cũng đồng nghĩa với việc máy chủ đang hoạt động với một CICAM hợp pháp.

Tiêu chuẩn này sử dụng các mã khóa mật dùng chung, được cả CICAM và máy chủ tính toán một cách độc lập, và thông tin đi qua giao diện chung đảm bảo một thiết bị thứ ba không đủ để tính toán ra mã khóa này. Quá trình này sử dụng những phương pháp thiết lập, thử và kiểm nghiệm mà hiện tại chúng chưa có điểm yếu cụ thể nào.

Tiêu chuẩn này chỉ áp dụng đối với việc tiếp nhận các dịch vụ được điều khiển bởi một hệ thống truy nhập có điều kiện và đã được các nhà cung cấp dịch vụ xáo trộn. Dịch vụ không được điều khiển bởi một hệ thống truy nhập có điều kiện nằm ngoài phạm vi của tiêu chuẩn này.

Tiêu chuẩn này được sử dụng kết hợp với quy trình cấp giấy chứng nhận phù hợp và phải dựa trên sự tuân thủ của nhà sản xuất đối với Các nguyên tắc Cl Plus bền vững [6] do Cơ quan cấp giấy chứng nhận kiểm soát.

Tiêu chuẩn này cũng cung cấp một danh sách các khuyến nghị để làm rõ hơn các tiêu chuẩn DVB-CI.

2  Tài liệu viện dẫn

Tài liệu viện dẫn sau rất cần thiết cho việc áp dụng tiêu chuẩn này. Đối với các tài liệu viện dẫn ghi năm công bố thì áp dụng phiên bản được nêu. Đối với các tài liệu viện dẫn không ghi năm công bố thì áp dụng phiên bản mới nhất, bao gồm cả sửa đổi, bổ sung (nếu có).

RSA PKCS#1 v2.1: June 14, 2002. RSA Cryptography Standard, RSA security inc. ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-1/pkcs-1v2-1.pdf. RSA PKCS # 1 v2.1:14 tháng Sáu 2002. Tiêu chuẩn mã RSA, Công ty an ninh RSA. ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-1/pkcs-1v2-1.pdf

FIPS PUB 46-3: October 25, 1999. National Institute of Standards and Technology, Data Encryption Standard (DES). http://csrc.nist.gov/publications/fips/fips46-3/fips46-3.pdf. FIPS PUB 46-3: 25 tháng 10 năm 1999. Viện Tiêu chuẩn và Công nghệ quốc gia, Tiêu chuẩn mã dữ liệu (DES). http://csrc.nist.gov/publications/fips/fips46-3/fips46- 3.pdf

FIPS PUB 180-3: October 2008. Secure Hash Signature Standard, NIST. http://csrc.nist.gov/publications/fips/fips180-3/fips180-3_final.pdf . FIPS PUB 180-3: Tháng Mười năm 2008. Tiêu chuẩn đóng dấu mã băm an ninh, NIST. http://csrc.nist.gov/publications/fips/fips180- 3/fìps180-3_final.pdf

FIPS PUB 197: November 26, 2001. Specification for the Advanced Encryption Standard (AES), National Institute of Standards and Technology, http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf

SCTE 41:2004. POD copy protection system. Society of Cable Telecommunications Engineers. Http://www.scte.org/documents/pdf/ANSISCTE412004.pdf. SCTE 41: 2004. Hệ thống bảo vệ sao chép POD. Hiệp hội kỹ thuật cáp viễn thông. http://www.scte.org/documents/pdf/ANSISCTE412004.pdf

Cl Plus Device Interim License Agreement http://www.ci-plus.com. Thỏa thuận cấp phép tạm thời thiết bị Cl Plus, http://www.ci-plus.com

CENELEC EN 50221: February, 1997. Common Interface Specification for Conditional Access and other Digital Video Broadcasting Decoder Applications, http://pda.etsi.org/pda/queryform.asp . CENELEC EN 50221: Tháng Hai, 1997. Bản quy định kỹ thuật giao diện chung dành cho truy nhập có điều kiện và các ứng dụng của bộ giải mã truyền hình kỹ thuật số khác, http://pda.etsi.org/pda/queryform.asp

ETSI TS 101 699 V1.1.1: November, 1999. Digital Video Broadcasting (DVB); Extensions to the Common Interface Specification Http://pda.etsi.org/pda/queryform.asp. ETSI TS 101 699 V1.1.1: Tháng Mười Một, 1999. Truyền hình kỹ thuật số (DVB); Phần mở rộng của bản quy định kỹ thuật giao diện chung. http://pda.etsi.org/pda/queryform.asp

ETSI TS 101 812: August 2006. Digital Video Broadcasting (DVB); Multimedia Home Platform (MHP) Specification 1.0.3. http://pda.etsi.org/pda/queryform.asp. ETSI TS 101 812: Tháng Tám năm 2006 Truyền hình kỹ thuật số; Nền tảng nhà ở đa phương tiện (MHP) Bản quy định kỹ thuật 1.0.3. http://pda.etsi.org/pda/queryform.asp

ETSI EN 300 468 V1.12.1 (2009-12): Digital Video Broadcasting (DVB); Specification for Service Information (SI) in DVB systems. http://pda.etsi.org/pda/queryform.asp. ETSI EN 300 468 V1.12.1 (2009-12): Truyền hình kỹ thuật số; Bản quy định kỹ thuật thông tin dịch vụ (SI) trong các hệ thống DVB. http://pda.etsi.org/pda/queryform.asp

SHS validation list. http://csrc.nist.gov/groups/STM/cavp/documents/shs/shaval.htm. Danh sách xác nhận SHS. http://csrc.nist.gov/groups/STM/cavp/documents/shs/shaval.htm

ANSI X 9.31: September 9, 1998. American National Standards Institute, Digital Signatures using reversible public key cryptography for financial services industry (rDSA). ANSI X 9,31:09 tháng chín năm 1998 Viện tiêu chuẩn quốc gia Hoa Kỳ, Các đóng dấu số sử dụng mã khóa công khai đảo ngược dành cho ngành công nghiệp dịch vụ tài chính (RDSA).

ISO/IEC 13818-1:2000(E). Information technology - Generic coding of moving pictures and associated audio information: Systems. ISO/IEC 13818-1: 2000 (E). Công nghệ thông tin - Mã hóa chung của các hình ảnh chuyển động và thông tin âm thanh liên quan: Các hệ thống.

ISO/IEC 13818-6:1998(E). Information technology - Generic coding of moving pictures and associated audio information, Extensions for DSM-CC. ISO/IEC 13.818-6:1998 (E). Công nghệ thông tin - Mã hóa chung của các hình ảnh chuyển động và thông tin âm thanh liên quan, phần mở rộng dành cho DSM-CC.

ISO/IEC 8859-1:1998. 8-bit single-byte coded graphic character sets, Part 1: Latin alphabet No. 1. ISO/IEC 8859-1:1998. Các bộ ký tự đồ họa mã hóa 1-byte 8-bit, Phần 1: Bảng chữ cái Latin số 1

ISO/IEC 13522-5:1997, Information technology - Coding of multimedia and hypermedia information - Part 5: Support for base-level interactive applications. ISO/IEC 13.522-5: năm 1997, công nghệ thông tin - Mã hóa thông tin đa phương tiện và hypermedia - Phần 5: Hỗ trợ cho các ứng dụng tương tác cấp cơ bản

TCVN 7217-1:2007 (ISO 3166-1:2006) về Mã thể hiện tên và vùng lãnh thổ của các nước - Phần 1: Mã nước

ISO 639-2:1998. Codes for the representation of names of languages - Part 2: Alpha-3 code. ISO 639- 2: 1998. Mã dành cho các ngôn ngữ - Phần 2: Mã Alpha-3.

RFC 3280: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile (version 3). http://www.ietf.org/rfc/rfc3280.txt. RFC3280. Hồ sơ danh sách thu hồi giấy chứng nhận (CRL) và Giấy chứng nhận cơ sở hạ tầng mã khóa công khai Internet X.509 (phiên bản 3) http://www.ietf.org/rfc/rfc3280.txt

RFC 3566, The AES-XCBC-MAC-96 Algorithm and Its Use With Ipsec, S. Frankel (NIST) H. Herbert (Intel), September 2003. RFC 3566,Thuật toán AES-XCBC-MAC-96 và sử dụng nó với Ipsec, S. Frankel (NIST) Herbert H. (Intel), tháng 9 năm 2003

RFC4055: Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. http://www.ietf.org/rfc/rfc4055.txt. RFC4055: Các thuật toán bổ sung và các nhãn nhận dạng dành cho mã RSA sử dụng trong hồ sơ danh sách thu hồi giấy chứng nhận (CRL) và Giấy chứng nhận cơ sở hạ tầng mã khóa công khai Internet X.509. http://www.ietf.org/rfc/rfc4055.txt

ITU-T Rec X.501: Series X: Data Networks And Open System Communications. ITU-T X.501: Mạng dữ liệu và truyền thông hệ thống mở.

DTG D-Book 5.0: Digital Terrestrial Television, Requirements for Interoperability Issue 5.0. http://www.dtg.org.uk/publications/books.html. DTG D-Book 5.0: Truyền hình kỹ thuật số mặt đất, Các yêu cầu tương thích, phiên bản 5,0. http://www.dtg.org.uk/publications/books.html

R206-001:1998. Guidelines for implementation and use of the common interface for DVB decoder applications. http://www.cenelec.org/Cenelec/Homepage.htm. R206-001: 1998. Hướng dẫn thực hiện và sử dụng giao diện chung dành cho các ứng dụng bộ giải mã DVB http:/www.cenelec.org/Cenelec/Homepage.htm

NIST Special Publication 800-38A, 2001 Edition, Computer Security Division, National Institute of Standards and Technology. Http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf. NIST Ấn phẩm đặc biệt 800-38A, 2001, Cục An ninh Máy tính, Viện Quốc gia Tiêu chuẩn và Công nghệ. http://csrc.nist.gov/publications/nistpubs/800- 38a/sp800-38a.pdf

ATSC Doc. A/70A:2004, July 22, 2004: Advanced Television Systems Committee, ATSC Standard: Conditional Access System for Terrestrial Broadcast, Revision A. ATSC Doc. A/70A: năm 2004, ngày 22 tháng 7 năm 2004: Ủy ban Hệ Thống Truyền Hình tiên tiến, tiêu chuẩn ATSC: Hệ thống truy nhập có điều kiện dành cho truyền hình mặt đất, bản sửa đổi A.

OC_SP_CCIF2.0-I07-061031: 2006-10-31. Cable Card Interface 2.0 Specification, Cable Television Laboratories. OC_SP_CCIF2.0-I07-061031: 2006/10/31. Bản quy định kỹ thuật giao diện thẻ truyền hình cáp 2.0, Phòng thí nghiệm truyền hình cáp

Thẻ PC Standard version 8.0 Volume 2 Electrical Specification: 2001-04. PCMCIA/JEITA Standardisation Committee. Tiêu chuẩn thẻ PC phiên bản 8.0 Tập 2 Bản quy định kỹ thuật điện: 2001-04. Ủy ban tiêu chuẩn PCMCIA/ JEITA

Thẻ PC Standard version 8.0 Volume 3 Physical Specification: 2001-04. PCMCIA/JEITA Standardisation Committee. Tiêu chuẩn thẻ PC phiên bản 8.0 Tập 3 Bản quy định kỹ thuật vật lý: 2001-04. Ủy ban Tiêu chuẩn PCMCIA/JEITA

Thẻ PC Standard version 8.0 Volume 4 Metaformat Specification: 2001-04. PCMCIA/JEITA Standardisation Committee . Tiêu chuẩn thẻ PC phiên bản 8.0 Tập 4 Bản quy định kỹ thuật Metaformat: 2001-04. Ủy ban tiêu chuẩn PCMCIA/ JEITA

PKCS #3: Diffie-Hellman Key Agreement Standard, ftp://ftp.rsasecurity.com/pub/pkcs/ascii/pkcs-3.asc. PKCS # 3: Tiêu chuẩn thương lượng mã khóa Diffie-Hellman ftp://ftp.rsasecurity.com/pub/pkcs/ascii/pkcs-3.asc

ETSI ETR 162:1995-10. Digital Video Broadcasting (DVB); Allocation of Service Information (SI) codes for DVB systems. ETSI ETR 162: 1995/10. Truyền hình kỹ thuật số; Phân bổ các mã thông tin dịch vụ (SI) cho các hệ thống DVB

Cl Plus Licensee Specification, available under licence from the Cl Plus Trust Authority. Đặc tả về giấy phép Cl Plus, có sẵn theo giấy phép của Cơ quan ủy quyền tin cậy Cl Plus.

High-bandwidth Digital Content Protection System, Interface Independent Adaptation, Revision 2.0. Hệ thống bảo vệ nội dung số băng thông rộng, thích ứng độc lập giao diện, phiên bản 2.0.

ETSI TS 102 757; Content Purchasing API. ETSI TS 102 757; API mua nội dung.

A Statistical Test Suite for Random and Pseudorandom Number Generators for Cryptographic Applications. http://csrc.nist.gov/groups/ST/toolkit/rng/documents/SP800-22b.pdf. Một phương pháp đo thống kê đối với các bộ tạo số ngẫu nhiên và giả ngẫu nhiên dành cho các ứng dụng mật mã. http://csrc.nist.gov/groups/ST/toolkit/rng/documents/SP800- 22b.pdf

Cl Plus Supplementary Specification, available under licence from the Cl Plus Trust Authority. Bản quy định kỹ thuật bổ sung Cl Plus, có sẵn theo giấy phép của Tổ chức tin cậy Cl Plus.

ETSI ES 202 184 V2.1.1. MHEG-5 Broadcast Profile. ETSI ES 202 184 v2.1.1. Hồ Sơ truyền hình MHEG- 5

ITU-T J.96:2001; Technical method for ensuring privacy in long-distance international MPEG-2 television transmission conforming to ITU-T J.89. ITU-T J.96: 2001; Phương pháp kỹ thuật để đảm bảo sự riêng tư trong truyền dẫn truyền hình MPEG-2 quốc tế khoảng cách xa phù hợp với ITU-T J.89

RFC 1123; Requirements for Internet Hosts -- Application and Support. RFC1123; Yêu cầu đối với máy chủ Internet - Ứng dụng và Hỗ trợ.

3  Định nghĩa, ký hiệu và chữ viết tắt

3.1  Định nghĩa

Theo mục đích của tiêu chuẩn này, các định nghĩa sau đây được áp dụng:

3.1.1

Xác thực (authentication)

Là thủ tục an toàn để xác nhận máy chủ hoặc CICAM có chứng nhận hợp lệ và không phải giả mạo, đồng thời thực hiện xác nhận an toàn về nguồn gốc của tin đến.

3.1.2

Được xác thực (Authenticated)

Một thông số chất lượng thu được từ việc áp dụng một thủ tục xác thực; được xác nhận an toàn.

3.1.3

Chế độ by-pass (bypass mode)

Chế độ hoạt động của máy chủ nơi đầu vào TS đến bộ giải ghép kênh của máy chủ được lấy trực tiếp từ nguồn (bộ dò kênh) mà không phải từ CICAM.

3.1.4

Băng truyền (Carousel)

Phương pháp truyền dữ liệu lặp lại trong một chu trình liên tục. Trong trường hợp này, thông qua một MPEG 2 TS.

3.1.5

CA-only

Chế độ CICAM có nội dung CA-descrambling EMI = 00 và trả lại cho máy chủ CC-unscrambled.

3.1.6

Cached PIN

Mã PIN mà đã gửi trong giao thức record_start

3.1.7

Nội dung được kiểm soát (controlled content)

Nội dung được kiểm soát có nghĩa là nội dung đã được truyền từ thiết bị đầu cuối với (a) các bit EMI được thiết lập một giá trị khác không, không (0,0), (b) các bit EMI được thiết lập một giá trị bằng không, không (0,0), nhưng có giá trị RCT được thiết lập là một (1).

3.1.8

CICAM (Common Interface Conditional Access Module)

Mô-đun truy nhập có điều kiện và có giao diện chung.

3.1.9

Giấy chứng nhận CICAM (CICAM Certificate)

Giấy chứng nhận duy nhất được cấp cho mỗi CICAM và được sử dụng để xác thực CICAM. Tên thông số: CICAM_DevCert.

3.1.10

Dữ liệu băng truyền (Data Carousel)

Một trong hai dạng băng truyền dữ liệu do DSM-CC, ISO 13.818-6 [14] quy định.

3.1.11

Máy chủ/Thiết bị chủ/chính (Host)

Thiết bị có khe CAM tuân thủ Cl Plus.

3.1.12

Giấy chứng nhận máy chủ (Host Certificate)

Giấy chứng nhận duy nhất được cấp cho mỗi máy chủ và được sử dụng để xác thực máy chủ. Tên thông số: Host_DevCert.

3.1.13

Mã hóa (Encrypted)

Dữ liệu được sửa đổi để ngăn chặn truy nhập trái phép (so sánh với “xáo trộn”)

3.1.14

Nonce

Một giá trị được chọn ngẫu nhiên được chèn vào một bản tin hoặc giao thức để bảo vệ chống lại các cuộc tấn công lặp lại.

3.1.15

Chế độ Pass-through

Một chế độ hoạt động của máy chủ nơi đầu vào TS đến bộ giải ghép kênh của máy chủ trước đó đã đi qua CICAM từ nguồn (bộ dò kênh).

3.1.16

Xáo trộn lại (re-scramble)

Chế độ của CICAM có nội dung CA-descrambling và CC-scrambling

3.1.17

Kênh được xác thực an toàn (Secure Authenticated Channel)

Đường truyền an toàn giữa máy chủ và CICAM.

3.1.18

Xáo trộn (Scrambled)

Nội dung được sửa đổi để ngăn chặn truy nhập trái phép (so sánh với “mã hóa”)

3.1.19

Tiếp nhận tin cậy (trusted reception)

Tiếp nhận dữ liệu SI không thông qua CICAM, tức là chế độ by-pass.

3.1.20

Nội dung không kiểm soát (uncontrolled content)

Nội dung được chỉ ra bởi giá trị EMI = 00.

3.1.21

Mã xem (viewing PIN)

Mã PIN được sử dụng để xem nội dung trực tiếp (live) hoặc nội dung đã ghi trong chế độ xem lại.

3.1.22

Chế độ/Chức năng tạm dừng (Timeshift/Timeshifting)

Chức năng cho phép tạm dừng chương trình rồi xem tiếp lại nội dung đã phát.

3.2  Ký hiệu

Theo mục đích của tiêu chuẩn này, các ký tự sau đây được áp dụng:

4  Tổng quan hệ thống

4.1  Giới thiệu

Hệ thống kiểm soát nội dung được mô tả trong tiêu chuẩn này nhằm hỗ trợ một liên kết an toàn dành cho các gói tin dòng truyền tải giữa một CICAM và một máy chủ. Hệ thống kiểm soát nội dung này xác định phần mở rộng đối với chuẩn DVB-CI để bổ sung các tính năng và bản tin giao thức trên cả hai thiết bị để bảo vệ nội dung được lựa chọn khỏi việc bị sao chép.

Nếu nội dung (nội dung xáo trộn CA hoặc nội dung rõ ràng) được người sử dụng lựa chọn không phải bảo vệ (tức là không có thông tin bảo vệ sao chép trong dòng truyền tải liên quan đến nội dung này) thì cả hai thiết bị nên tuân thủ chuẩn DVB-CI EN 50221 [7] & TS 101 699 [8].

Tổng quan về hệ thống được mô tả trong hình 4.1. Nội dung giá trị cao có thể được bảo vệ từ thiết bị đầu cuối đến máy chủ bởi hệ thống CA. Tuy nhiên, khi nội dung đã được giải điều chế và việc xáo trộn của hệ thống CA đã được gỡ bỏ thì nội dung dễ bị sao chép khi nó được truyền qua giao diện chung. Đây là công việc của hệ thống kiểm soát nội dung được quy định trong tiêu chuẩn này để bảo vệ nội dung AV khi nội dung được truyền qua giao diện chung và đến các giao diện AV bên ngoài.

Hình 4.1 - Tổng quan hệ thống

4.2  Các thành phần của hệ thống kiểm soát nội dung

Theo mục đích của tiêu chuẩn này, hệ thống kiểm soát nội dung bao gồm các thành phần sau (xem hình 4.1):

• Thiết bị thu DTV (Máy chủ)

• CICAM

• Thiết bị đầu cuối (Head-end)

Việc bảo vệ phương tiện trước khi hệ thống CA gây hiệu ứng xáo trộn không được xem xét trong tiêu chuẩn này. Tương tự như vậy, ngoài việc truyền thông tin các quy tắc sử dụng (URI), những gì xảy ra với phương tiện sau khi trả lại máy chủ và được giải mã không được xem xét trong tiêu chuẩn này.

Ba thành phần nói trên được mô tả ngắn gọn trong các phần sau:

4.2.1  Máy chủ

Trong phạm vi của tiêu chuẩn này, máy chủ là một thiết bị điện tử tiêu dùng được sử dụng để thu và điều khiển các phương tiện truyền hình kỹ thuật số. Thiết bị này phải có một hoặc nhiều khe cắm giao diện chung dành cho CICAM.

Thông thường, máy chủ có một bộ dò kênh có dạng nào đó, bộ giải điều chế, bộ giải ghép kênh (Demux) và các bộ giải mã phương tiện. Chúng là những điều kiện tiên quyết cho việc thu truyền hình kỹ thuật số. Đối với nội dung miễn phí, chúng là tất cả những gì cần thiết để thu và giải mã nội dung kỹ thuật số, đối với nội dung được một hệ thống CA bảo vệ thì máy chủ phải có một CICAM.

DVB CICAM tuân thủ chuẩn EN 50221 [7] không có hệ thống kiểm soát nội dung để bảo vệ nội dung đã được giải xáo trộn. Nội dung đã gỡ bỏ sự bảo vệ của hệ thống CA được truyền đến máy chủ không được bảo vệ. Máy chủ tuân thủ tiêu chuẩn này có thể phối hợp với CICAM để cung cấp một hệ thống kiểm soát nội dung an toàn để bảo vệ nội dung có giá trị cao đã được CA giải xáo trộn.

Máy chủ có thể xác định xem CICAM ghép vào giao diện chỉ tuân thủ chuẩn EN 50221 [7] hay CICAM tuân thủ thêm tiêu chuẩn này. Máy chủ phải hoạt động với cả CICAM Cl Plus và EN 50221 [7] như được nêu trong Bảng 4.1. Nội dung truyền hình miễn phí không bị Cl Plus ngăn cản.

Bảng 4.1 - Khả năng phối hợp giữa CICAM và máy chủ (tham khảo)

Máy chủ bao gồm một bộ công cụ mã hóa và các tính năng cho phép nó kiểm tra xem CICAM được ghép có là một CICAM được xác thực và tin cậy.

4.2.2  CICAM

CICAM bao gồm đầu cuối hệ thống CA của người sử dụng. Nó bao gồm một bộ giải mã CA, giao diện thẻ thông minh tùy chọn và phần mềm để cho phép các mã khóa giải mã được tính toán bằng cách sử dụng dữ liệu từ các dòng thu được.

Đối với các phiên bản không phải là Cl Plus của giao diện chung, nội dung được truyền hoàn toàn không mã hóa đến máy chủ thông qua kết nối Cl và bỏ qua việc chặn hay sao chép nội dung. Tiêu chuẩn này đảm bảo bất kỳ nội dung được thông báo là cấm sao chép được CICAM mã hóa tại chỗ bằng một hệ thống kiểm soát nội dung trước khi được truyền đến máy chủ.

Ngoài hệ thống bảo vệ cung cấp CA, CICAM bao gồm các công cụ mã hóa và các tính năng cho phép nó xác thực độ tin cậy của máy chủ mà nó đã được ghép vào. Nếu CICAM xác thực máy chủ, nó giải xáo trộn một dịch vụ truyền hình và áp dụng mã hóa kiểm soát nội dung đối với nội dung này.

4.2.3  Thiết bị đầu cuối (Head-end)

Thiết bị đầu cuối là nơi hệ thống CA xáo trộn nội dung bằng cách sử dụng bộ mã hóa hệ thống CA. Thiết bị đầu cuối cũng đưa vào dòng truyền tải các thông tin cụ thể CA khác cho phép CICAM giải xáo trộn nội dung này và quản lý các truy nhập và quyền của thuê bao.

4.3  Nguyên tắc hoạt động chung

Hệ thống kiểm soát nội dung CICAM bao gồm ba thành phần hoạt động sau đây:

• Xác thực máy chủ; dựa trên việc trao đổi giấy chứng nhận máy chủ và CICAM. Mỗi thiết bị kiểm tra giấy chứng nhận của thiết bị kia bằng cách sử dụng các kỹ thuật kiểm tra đóng dấu. Host ID được CICAM (BSM) hoặc Thiết bị đầu cuối (RSM) kiểm tra với một danh sách thu hồi và thực hiện hành động thu hồi thích hợp đối với các thiết bị bị nghi ngờ.

• Kiểm soát nội dung; việc xáo trộn trong kiểm soát nội dung của CICAM đối với nội dung yêu cầu việc truyền được bảo vệ từ CICAM đến máy chủ.

• An toàn nội dung; truyền an toàn các quy tắc sử dụng nội dung từ hệ thống CA đến máy chủ để cho phép việc áp dụng các hạn chế phù hợp đối với các kết nối đầu ra bất kỳ.

Trước tiên, CICAM giải xáo trộn CA đối với nội dung và sau đó xáo trộn lại nội dung “giá trị cao” bằng cách sử dụng CCK trước khi truyền đến máy chủ. Một quá trình giải xáo trộn trong kiểm soát nội dung tương tự xảy ra trong máy chủ.

4.4  Xác thực thiết bị

Hệ thống kiểm soát nội dung yêu cầu xác thực máy chủ và CICAM trước khi kiểm soát nội dung yêu cầu CICAM giải xáo trộn bất kỳ nội dung đã được xáo trộn CA. CICAM yêu cầu giấy chứng nhận của máy chủ và máy chủ cung cấp nó. Máy chủ yêu cầu giấy chứng nhận của CICAM và CICAM cung cấp nó.

Việc xác thực được dựa trên:

• CICAM có thể kiểm tra đóng dấu của giấy chứng nhận thiết bị của máy chủ có chứa Host ID.

• Máy chủ có thể kiểm tra đóng dấu của giấy chứng nhận của CICAM có chứa CICAM ID.

• CICAM và máy chủ chứng minh chúng giữ mã khóa riêng liên kết cặp với mã khóa công khai được nhúng trong giấy chứng nhận bằng cách tạo một mã khóa phiên DH và gửi nó cho thiết bị kia để kiểm tra đóng dấu.

• CICAM và máy chủ chứng minh rằng chúng có thể tạo mã khóa xác thực.

4.5  Trao đổi mã khóa và mã hóa nội dung

Cơ chế kiểm soát nội dung bao gồm bốn giai đoạn:

• Thiết lập

• Tạo mã khóa

• Mã hóa nội dung.

• Mã hóa nội dung tùy thuộc vào các giá trị URI được truyền một cách an toàn bởi cơ chế kiểm soát nội dung.

Tiêu chuẩn này mở rộng sự kiểm soát nội dung với:

• Kiểm soát của cha mẹ (quản lý mã PIN)

• Quyền liên kết với ghi lại được truyền một cách an toàn bởi cơ chế kiểm soát nội dung.

• URI phiên bản 2 mở rộng giới hạn lưu giữ

CICAM và máy chủ (Host) cả hai đều chứa các thuật toán dành cho đàm phán mã khóa Diffie-Helman (DH), thuật toán băm SHA-256, DES và AES. CICAM và máy chủ cũng giữ các mã khóa riêng và mã khóa công khai tương ứng.

4.6  MMI nâng cao

Cl Plus giới thiệu một công cụ trình bày tiêu chuẩn vào hồ sơ Cl để trình bày văn bản và hình ảnh trên màn hình máy chủ mà không cần yêu cầu phải có phần mở rộng hơn nào đối với MMI ứng dụng. Công cụ trình bày cho phép CICAM trình bày thông tin với cái nhìn và cảm nhận theo quy định của các nhà điều hành dịch vụ chứ không phải bị hạn chế đối với MMI cấp cao của các nhà sản xuất.

Tiêu chuẩn này mở rộng hồ sơ ứng dụng để bao gồm hỗ trợ cho các ứng dụng truyền hình theo yêu cầu.

Việc hỗ trợ MMI ứng dụng cho “trình duyệt Cl Plus” được mô tả trong điều 12 đối với một máy chủ là bắt buộc. Các yêu cầu tài nguyên MMI cấp cao hiện có được mô tả trong điều 13.

4.7  Các mở rộng của Cl Plus

Cl Plus giới thiệu một số cải tiến các tài nguyên DVB-CI hiện có, ngoài một số tài nguyên mới được mô tả trong điều 14, bao gồm:

• Cung cấp các kết nối đường truyền tốc độ thấp qua IP có thể được sử dụng để hỗ trợ các chức năng truy nhập có điều kiện.

• Nâng cấp phần mềm CAM tạo điều kiện cho việc nâng cấp phần mềm của CICAM phối hợp với máy chủ, chuẩn hoá tương tác giữa CICAM và Host. Hỗ trợ máy chủ nâng cấp phần mềm là bắt buộc.

Các yêu cầu an toàn Cl Plus và các mở rộng Cl Plus yêu cầu truyền nhanh hơn qua liên kết Cl được xử lý trong Phụ lục G. Làm rõ các trường hợp sử dụng DVB-CI được quy định tại Phụ lục E.

4.7.1  Các mở rộng của Cl Plus 1.3

Cl Plus 1.3 giới thiệu một số cải tiến các tài nguyên trong Cl Plus 1.2 và DVB-CI và thêm vào một số tài nguyên mới được mô tả trong điều 14, bao gồm:

• Các mở rộng đối với tài nguyên đường truyền tốc độ thấp mà loại bỏ một số hạn chế của phiên bản trước đó để cải thiện thông lượng. Tài nguyên đường truyền tốc độ thấp là bắt buộc đối với tất cả các máy chủ có hỗ trợ kết nối IP.

• Tài nguyên hồ sơ nhà điều hành mới cung cấp một hồ sơ truyền hình theo chuẩn Cl Plus và sử dụng CICAM để dịch bất kỳ thông báo riêng của mạng sang một cấu trúc thông tin thống nhất cho phép tất cả các máy chủ Cl Plus thực hiện cài đặt hoàn toàn và một danh sách kênh của tất cả các dịch vụ theo yêu cầu của các nhà điều hành dịch vụ.

• Điều khiển máy chủ phiên bản 2 thêm các lệnh mới cho CICAM để điều chỉnh máy chủ đến một dịch vụ không thuộc bảng sắp xếp kênh của máy chủ. Dịch vụ được lựa chọn này được dựa trên mô tả vật lý của dòng truyền tải có mang dịch vụ này và nhận dạng của dịch vụ này.

5  Tổng quan kiểm soát nội dung

Mục đích chính của tiêu chuẩn này là để bảo vệ nội dung nhận được, sau khi bất kỳ hệ thống CA xáo trộn đã được gỡ bỏ, khi nội dung truyền qua giao diện chung đến máy chủ. Điều này được thực hiện bằng:

• Xác thực lẫn nhau giữa CICAM và máy chủ.

• Kiểm tra máy chủ và CICAM.

• Tính toán mã khóa mã hóa.

• Truyền tải sử dụng một kênh xác thực an toàn.

Các thủ tục này được mô tả chi tiết trong tiêu chuẩn này.

5.1  Kiến trúc

Theo mục đích của tiêu chuẩn này, hệ thống hoàn chỉnh bao gồm tất cả mọi thứ từ thiết bị đầu cuối đến máy chủ bao gồm cả CICAM. Hướng lên của Thiết bị đầu cuối không nằm trong phạm vi tiêu chuẩn này. Bất kỳ kết nối giữa máy chủ và các thiết bị khác không được xem xét trong tiêu chuẩn này. Tiêu chuẩn này đề cập đến việc truyền thông tin các quy tắc sử dụng mà máy chủ phải sử dụng khi trình bày phương tiện đến giao diện bên ngoài có liên quan bất kỳ.

Hình 5.1- Sơ đồ chỉ ra phạm vi của các cơ chế bảo vệ

Hình 5.1 cho thấy hệ thống đầu cuối đến đầu cuối và chỉ ra phạm vi của bảo vệ CA và hệ thống kiểm soát nội dung được mô tả trong tiêu chuẩn này. Tiêu chuẩn này đề cập đến giao diện giữa CICAM và máy chủ được bảo vệ bởi hệ thống kiểm soát nội dung. Kiểm soát nội dung hoạt động với sự hỗ trợ của hệ thống CA và một bộ công cụ mã hóa để bảo vệ cho phương tiện đến máy chủ. Máy chủ, sử dụng một bộ các công cụ mã hóa tương tự, loại bỏ việc bảo vệ này và đưa nội dung đến các bộ giải mã của máy chủ.

5.2  Tổng quan về hành vi giao diện

Các hành vi khởi tạo khi bật điện lên được mô tả trong tài liệu EN 50221 [7].

Tài nguyên CC, được định nghĩa trong tiêu chuẩn này, được sử dụng để bảo vệ nội dung a) khi nội dung được truyền từ CICAM sang máy chủ và b) Nếu và khi nội dung được đưa đến giao diện bên ngoài của máy chủ. Nhiều bước tham gia vào quá trình này. Các thành phần hệ thống này sử dụng tài nguyên CC để bắt đầu một quá trình xác thực lẫn nhau. Khi CICAM và máy chủ đã cùng xác nhận rằng chúng đang liên lạc với thành phần Cl Plus hợp pháp thì một kênh xác thực an toàn (SAC) được khởi tạo. SAC được sử dụng để truyền các bản tin chuyển được xác thực và mã hóa. Các thành phần hệ thống này thiết lập một mã khóa xáo trộn/giải xáo trộn CC chung và trao đổi thông tin các quy tắc sử dụng và giấy phép tùy chọn. Quá trình này được giải thích trong hình 5.2, trong bảng 5.1 đề cập đến các mục trong tiêu chuẩn này cung cấp các cơ chế chi tiết.

CHÚ THÍCH: Lưu đồ này không thể hiện rằng mọi hành vi (không) được đồng bộ/khối hóa.

Hình 5.2 - Hành vi giao diện cấp cao

Quá trình này được xác định như mô tả trong Bảng 5.1:

Bảng 5.1 - Hành vi giao diện cấp cao

5.3  Phân cấp mã khóa

Một hệ thống phân cấp mã khóa được sử dụng để thực hiện bảo vệ nội dung và kiểm soát sao chép được thể hiện trong hình 5.3.

Hình 5.3 - Hệ thống phân cấp mã khóa

Bảng 5.2 - Mã khóa so với các giấy chứng nhận

5.3.1  Các mã khóa trên lớp chứng nhận

Có một cặp mã khóa công khai và riêng được xác định dành cho CICAM và dành cho máy chủ. CICAM có một mã khóa riêng thiết bị (MDQ) và mã khóa công khai thiết bị tương ứng (MDP) được nhúng trong giấy chứng nhận thiết bị của CICAM. Máy chủ tương tự cũng chứa HDQ và HDP. Có một chuỗi chứng nhận duy nhất cho cả CICAM và máy chủ. Có hằng số được sử dụng trong tính toán, chẳng hạn như DH_p và DH_g đối với quá trình xác thực Diffie-Hellman.

Dữ liệu trên lớp chứng nhận (như mã khóa, nhân, giấy chứng nhận và các hằng số như đề cập trong bảng 5.2) được tham gia vào các hoạt động trên lớp chứng nhận. Lớp chứng nhận chứa các thông số không được thay thế. Tiêu chuẩn này không chỉ rõ cơ chế chính xác được sử dụng để bảo vệ các thông số của lớp chứng nhận này, điều này nằm ngoài phạm vi của tiêu chuẩn này.

5.3.2  Các mã khóa trên lớp xác thực

Mã khóa công khai thiết bị, từ giấy chứng nhận thiết bị, và mã khóa riêng thiết bị có liên quan đến hai hoạt động (Không thể hiện trong hình 5.3):

1) Bảo vệ việc trao đổi thông số trong quá trình xác thực. Việc xác thực dựa trên Diffie-Hellman, yêu cầu CICAM và máy chủ trao đổi các thông số phải được bảo vệ chống lại việc làm thay đổi từ một nguồn độc hại. Tham khảo điều 6.1.2 để biết chi tiết.

2) Kiểm tra chuỗi chứng nhận. Chuỗi chứng nhận chứa thông tin được sử dụng trong các bước tiếp theo trong phân cấp mã khóa. Các giấy chứng nhận thu được phải được hai bên xác nhận, tham khảo điều 9.4 và điều 9 để biết chi tiết.

Các mã khóa thu được từ lớp xác thực là mã khóa mật Diffie-Hellman (DHSK) và mã khóa xác thực (AKM dành cho CICAM và AKH dành cho máy chủ). CICAM yêu cầu mã khóa xác thực này được máy chủ sử dụng. Tham khảo điều 6 để biết chi tiết.

DHSK và AKM hoặc AKH được lớp xác thực bảo vệ và quản lý. Các lớp khác (chẳng hạn như lớp SAC và lớp kiểm soát nội dung) đôi khi có thể yêu cầu các mã khóa này để tính các thông số mật không ổn định của chúng. Lớp xác thực truyền các mã khóa được yêu cầu nhưng lớp sử dụng không được duy trì hoặc lưu trữ chúng.

5.3.3  Các mã khóa trên lớp SAC

Lớp SAC sử dụng các mã khóa để xác thực và mã hóa bản tin trước khi được gửi đi. Phần nhận được sử dụng các mã khóa được tính toán tương tự để giải mã và kiểm tra bản tin. Mã khóa xác thực SAC (SAK) được sử dụng để xác thực và kiểm tra bản tin SAC. Tương tự như vậy mã khóa mã hóa SAC (SEK) được sử dụng để mã hóa và giải mã bản tin SAC. SAK và SEK được tính độc lập ở CICAM và máy chủ. SAK và SEK đều là thông số mật ngắn hạn không ổn định. Tham khảo điều 7 để biết chi tiết.

Hình 5.4 - Các mã khóa trên lớp SAC

5.3.4  Các mã khóa trên lớp kiểm soát nội dung (CC)

Lớp CC sử dụng các mã khóa để xáo trộn nội dung AV trước khi nó được truyền từ CICAM đến máy chủ. Mã khóa kiểm soát nội dung, CCK, (và nếu cần CIV) được sử dụng để xáo trộn AV. Về phía nhận được, máy chủ sử dụng các mã khóa được tính toán tương tự để giải mã nội dung AV. CCK (và nếu cần CIV) được tính toán một cách độc lập ở CICAM và máy chủ. CCK (và nếu cần CIV) đều là thông số mật không ổn định, ngắn hạn. Tham khảo điều 8 để biết chi tiết.

Hình 5.5 - Các mã khóa trên lớp CC

5.4  Triển khai mô-đun

CICAM có thể được triển khai trong chế độ dịch vụ cơ bản (BSM) hoặc chế độ đăng ký dịch vụ (RSM). Chế độ dịch vụ cơ bản là bắt buộc, chế độ đăng ký dịch vụ là tùy chọn và tuân thủ SCTE41 [5]. SCTE41 quy định ba giai đoạn xác thực:

1) Kiểm tra giấy chứng nhận & trao đổi mã khóa DH

2) Kiểm tra mã khóa xác thực

3) Báo cáo trả về thiết bị đầu cuối

Cả hai dịch vụ chế độ hỗ trợ giai đoạn xác thực 1 và 2. Chỉ có chế độ đăng ký dịch vụ hỗ trợ giai đoạn xác thực thứ ba: Báo cáo trả về thiết vị đầu cuối (xem Bảng 5.3)

Bảng 5.3  - Các giai đoạn xác thực được hỗ trợ đối với mỗi chế độ dịch vụ

Trong chế độ dịch vụ cơ bản và đăng ký dịch vụ, CICAM có thể hoạt động ở hai trạng thái:

• Hoạt động hạn chế; chế độ tương thích EN 50221 [7]. Không có dịch vụ yêu cầu bảo vệ Cl Plus được giải xáo trộn CA.

• Hoạt động toàn phần; chế độ tương thích Cl Plus. Tất cả dịch vụ được Cl Plus bảo vệ được xáo trộn lại theo Cl Plus.

Hai điều tiếp theo giải thích cả hai chế độ một cách chi tiết hơn, điều thứ ba mô tả cách CICAM và máy chủ xử lý lỗi.

5.4.1. Triển khai trong chế độ dịch vụ cơ bản

Chế độ dịch vụ cơ bản xác định hoạt động của CICAM trong một môi trường truyền hình (tức là không có kênh thông tin hai chiều trực tuyến). CICAM không hoạt động ngay lập tức khi được ghép vào thiết bị máy chủ và nguồn điện đã được bật; trước đó các giao thức sau đây phải được thực hiện:

• Xác thực lại khi bật nguồn điện (xem điều 6.3)

• Kiểm tra giấy chứng nhận & trao đổi mã khóa DH (xem điều 6.2)

• Kiểm tra mã khóa xác thực (xem điều 6.3)

• Thiết lập kênh xác thực an toàn (SAC) (xem điều 7)

• Thiết lập mã khóa kiểm soát nội dung (CC) (xem điều 8)

Hình 5.6 - Quá trình xác thực trong chế độ dịch vụ cơ bản.

Hình 5.6 đưa ra một cái nhìn tổng quan về quá trình xác thực trong chế độ dịch vụ cơ bản. Khi bật nguồn điện, trước tiên CICAM xác định xem thiết bị máy chủ có tương thích Cl Plus. Máy chủ tương thích Cl Plus thông báo tài nguyên CC trong giao thức quản lý tài nguyên lúc khởi tạo, xem điều 12.3 và EN 50221 [7] điều 8.4.1.1 (2). Trong trường hợp, thiết bị máy chủ không tương thích một lỗi mô tả (xem Hình 5.10) được đưa ra bằng cách sử dụng MMI cấp cao hoặc MMI ứng dụng (3) và CICAM ở chế độ hoạt động hạn chế (10) (tức là tương thích EN 50.221). Khi thiết bị máy chủ tương thích Cl Plus máy chủ sẽ kiểm tra xem có thẻ xác thực lại khi bật nguồn điện (4). Xác thực lại khi bật nguồn điện là có thể khi CICAM trước đó đã liên kết thành công với thiết bị máy chủ này. Khi có liên kết thành công thì kiểm tra giấy chứng nhận và trao đổi mã khóa DH (5) và kiểm tra mã khóa xác thực (6) có thể được bỏ qua, và CICAM có thể bắt đầu ngay lập tức với thiết lập SAC (7). Sau khi thiết lập SAC thì thiết lập mã khóa CC (8). Với SAC và mã khóa CC được thiết lập, CICAM ở chế độ hoạt động hoàn toàn (9).

SAC được sử dụng để truyền nội dung thông tin các quy tắc sử dụng (URI) một cách an toàn. URI là liên kết với một dịch vụ/sự kiện được bảo vệ CA và truyền thông tin kiểm soát sao chép đến các đầu ra thiết bị máy chủ số (EMI) và tương tự (APS) (xem điều 5.7.5.4). Thiết bị máy chủ sử dụng các quy tắc sử dụng mặc định, hạn chế nhất cho đến khi giao thức truyền URI được kết thúc thành công (xem điều 5.7.5) và sự kiện liên quan các quy tắc sử dụng được thông báo cho thiết bị máy chủ.

Các mã khóa CC được sử dụng để mã hóa của các dịch vụ được Cl Plus CICAM bảo vệ và giải mã các dịch vụ được Cl Plus thiết bị máy chủ bảo vệ. Thiết bị máy chủ suy ra mã khóa CC từ việc trao đổi mã khóa DH; không có mã khóa CC được truyền từ CICAM đến thiết bị máy chủ. Hình 5.7 đưa ra tổng quan của quá trình thiết lập mã khóa CC và SAC, ở bước (3) và (5) khi mã khóa được làm mới ở bước (2) và (4) được yêu cầu. Nếu vì một lý do SAC hoặc mã khóa CC không được làm mới lại (6) và (7) thì CICAM trở lại trạng thái hoạt động hạn chế (8) nếu không trạng thái của nó vẫn là hoạt động hoàn toàn (1).

Hình 5.7 - Quá trình làm mới lại SAC và mã khóa CC

Chế độ dịch vụ cơ bản hỗ trợ việc thu hồi thiết bị máy chủ bằng một Danh sách thu hồi giấy chứng nhận (CRL) do Thiết bị đầu cuối truyền đến CICAM sử dụng một băng truyền dữ liệu DSM-CC. Trong trường hợp của một thiết bị máy chủ bị thu hồi, CICAM thông báo cho người sử dụng rằng thiết bị máy chủ của họ trong danh sách đen sử dụng tính năng thông báo lỗi chung (xem điều 5.4.3).

Ngoài CRL, chế độ dịch vụ cơ bản hỗ trợ một Danh sách trắng giấy chứng nhận (CWL) cho phép các nhà điều hành dịch vụ trở lại trạng thái thu hồi trước đó của một thiết bị máy chủ duy nhất. Xem điều 5.5 để biết chi tiết về cơ chế thu hồi Cl Plus.

5.4.2. Triển khai trong chế độ đăng ký dịch vụ

Chế độ đăng ký dịch vụ là một phần mở rộng của Chế độ dịch vụ cơ bản và được thiết kế cho các mạng có khả năng giao tiếp thông tin hai chiều từ CICAM tới mạng hệ thống quản lý thuê bao. Để thực thi Chế độ đăng ký dịch vụ, CICAM có thể sử dụng High-Level hoặc ứng dụng MMI để đưa ra hướng dẫn và dữ liệu đăng ký đến người dùng nhằm giao tiếp tới mạng hệ thống quản lý thuê bao.

Các hoạt động của Chế độ đăng ký dịch vụ được xác định bởi nhà khai thác dịch vụ và nằm ngoài phạm vi của tiêu chuẩn này.

5.4.3. Báo cáo lỗi tổng quát

Các Lỗi có thể được phát hiện và báo cáo bởi CICAM hoặc Máy chủ. Khi một lỗi được phát hiện bởi CICAM thì nó sẽ sử dụng High-Level hoặc ứng dụng MMI để hiển thị một mã lỗi được quy định trước. Khi Máy chủ phát hiện lỗi thì nó có thể sử dụng một vài phương pháp cụ thể trên máy chủ để hiển thị mã lỗi đã được quy định trước. Các mã lỗi có thể kèm theo văn bản mô tả và phải được xác nhận bởi sự tương tác của người dùng. Phụ lục F định nghĩa các điều kiện lỗi tiêu chuẩn và các mã lỗi.

Trường hợp CICAM hỗ trợ Chế độ đăng ký dịch vụ, nhà cung cấp CA hay nhà khai thác dịch vụ có thể xác định một liên kết giữa hành động và các mã lỗi. Các nhà cung cấp CA hoặc nhà khai thác dịch vụ phải xác định mã hành động đã được hỗ trợ trong Chế độ đăng ký dịch vụ và không thuộc phạm vi của tiêu chuẩn này.

Ví dụ: Mã yêu cầu hành động được liên kết với mã lỗi “invalid Host certificate”, Phụ lục F.1 xác định tình trạng lỗi này là Mã lỗi số 16 (Error Code 16), nhà cung cấp CA hoặc nhà khai thác dịch vụ có thể liên kết lỗi này tới bất kỳ Mã yêu cầu hành động nào. Kết quả là Bản tin Thông báo sẽ cung cấp thông tin cho khách hàng cùng với hướng dẫn liên hệ số điện thoại hỗ trợ.

5.5. Giới thiệu phương pháp thu hồi (tham khảo)

Tiêu chuẩn này quy định một phương pháp thu hồi để xử lý đối với thiết bị máy chủ bị nghi ngờ về an toàn. Tiêu chuẩn này phân biệt ba cơ chế thu hồi:

1) Ngăn chặn dịch vụ của máy chủ

2) Thu hồi bằng CAS

3) Thu hồi máy chủ

Ngăn chặn dịch vụ của máy chủ được mô tả chi tiết trong điều 10. Thu hồi bằng CAS được một CAS cụ thể quy định và do đó nằm ngoài phạm vi tiêu chuẩn này. Phần còn lại của điều này mô tả cơ chế thu hồi máy chủ, chuẩn giấy cấp phép Cl Plus quy định các yêu cầu để thực hiện thu hồi máy chủ.

5.5.1. Thu hồi máy chủ

Thu hồi máy chủ là thu hồi bằng từ chối dịch vụ tức là CICAM dừng hoạt động Cl Plus, không cung cấp cho thiết bị máy chủ các dịch vụ kiểm soát nội dung của Cl Plus. Tổ chức thiết bị bị thu hồi được liệt kê trong một danh sách thu hồi giấy chứng nhận (SOCRL). Các danh sách thu hồi sau đây được quy định cho mục đích này:

• Danh sách thu hồi giấy chứng nhận nhà điều hành dịch vụ (SOCRL)

• Danh sách trắng giấy chứng nhận nhà điều hành dịch vụ (SOCWL)

Một SOCRL được Nguồn gốc tin cậy tạo ra theo yêu cầu của một nhà điều hành dịch vụ đặc biệt dành cho hoạt động này. Thu hồi luôn luôn gắn liền với một nhà điều hành dịch vụ cụ thể. Một thiết bị máy chủ có thể bị thu hồi đối với một nhà điều hành dịch vụ mà vẫn hoạt động với những nhà điều hành dịch vụ khác. Thu hồi thiết bị máy chủ chỉ áp dụng đối với các dịch vụ được các nhà điều hành dịch vụ được Cl Plus bảo vệ (ví dụ như nội dung HD cao cấp) yêu cầu nhưng cho phép các dịch vụ khác (ví dụ: nội dung giá trị thấp được CA bảo vệ CA) vẫn có thể truy nhập đến máy chủ. Các đầu vào trong SOCWL bỏ một thu hồi được quy định trong SOCRL.

Để đảm bảo thu nhận một SOCRL bởi CICAM, SOCRL nên là một phần của mỗi dòng truyền tải (TS) mang các dịch vụ thuộc nhà điều hành dịch vụ. Trường hợp TS có các dịch vụ thuộc hai hoặc nhiều nhà điều hành dịch vụ thì một SOCRL cho mỗi nhà điều hành dịch vụ phải được thêm vào TS.

Các quy tắc chính xác để thu hồi một thiết bị được Chuẩn cấp giấy phép Cl Plus quy định, do đó nằm ngoài phạm vi tiêu chuẩn này, xem Chuẩn cấp giấy phép Cl Plus [33].

Mô hình tin cậy để thu hồi quy định hai phần từ: 1) CICAM và 2) thiết bị máy chủ. Thiết bị máy chủ là mục tiêu của việc thu hồi và được xem là không đáng tin cậy. Các mối đe dọa sau đây được xem xét:

1) Phát lại; thiết bị máy chủ có thể phát lại một SOCRL không chứa nhận dạng của nó.

2) Ngăn chặn; thiết bị máy chủ có thể ngăn chặn SOCRL tiếp cận CICAM.

3) Giả mạo; thiết bị máy chủ có thể thay đổi hoặc loại bỏ một đầu vào SOCRL có chứa nhận dạng của nó.

Mối đe dọa đầu tiên được xử lý bằng cách thêm một mốc dấu thời gian hoặc bộ đếm vào SOCRL. Mối đe dọa thứ hai được xử lý bằng cách quy định một giới hạn chu kỳ bắt buộc; CICAM phải thu được một SOCRL trong một cửa sổ thời gian được xác định trước (với một khoảng thời gian đáng kể để ngăn chặn các điều kiện hiếm gặp). Để ngăn chặn giả mạo, một SOCRL được mã khóa RSA riêng của nhà điều hành dịch vụ đóng dấu và được nhà điều hành dịch vụ nhà phân phối đến các CICAM trong mạng của họ. Một CICAM có thể kiểm tra tính toàn vẹn của một SOCRL bằng cách sử dụng mã khóa công khai RSA trong giấy chứng nhận của nhà điều hành dịch vụ. Giấy chứng nhận này lại được giấy chứng nhận nguồn gốc tin cậy kiểm tra (Xem điều 9).

5.5.2. Mức độ thu hồi

Tiêu chuẩn này hỗ trợ các mức thu hồi:

1) Thiết bị máy chủ duy nhất

2) Dải các thiết bị máy chủ

3) Thiết bị máy chủ có một mô hình-kiểu cụ thể

4) Thiết bị máy chủ có một thương hiệu cụ thể

Một nhà điều hành dịch vụ có thể sử dụng một mức bất kỳ khi yêu cầu thu hồi máy chủ. SOCWL chỉ hỗ trợ thiết bị máy chủ duy nhất được bỏ thu hồi từ một dải bị thu hồi. Tính năng này có thể được sử dụng để kiểm tra thiết bị riêng lẻ trong một dải thiết bị bị thu hồi.

5.5.3. Dữ liệu thông báo thu hồi

Thông tin dữ liệu thông báo thu hồi (RSD) chỉ ra tính sẵn có của một SOCRL (và SOCWL) trong mạng. RSD phải mang:

1) nhận dạng nhà điều hành dịch vụ; quy định các nhà cung cấp dịch vụ được Cl Plus bảo vệ, SOCRL và SOCWL.

2) thông tin tải SOCRL và/hoặc SOCWL; chứa thông tin mà CICAM yêu cầu tìm SOCRL và SOCWL trong dòng truyền tải. Nếu không có thông tin tải được quy định thì nhà điều hành dịch vụ không truyền một SOCRL và/hoặc SOCWL.

3) số phiên bản SOCRL và/hoặc SOCWL mới nhất; các số phiên bản SOCRL và SOCWL mới nhất hiện đang được truyền.

4) thời gian chờ truyền SOCRL và SOCWL; quy định thời gian truyền SOCRL và SOCWL. SOCRL và SOCWL phải được thu trước khi hết khoảng thời gian chờ nếu không CICAM trở thành hoạt động hạn chế.

RSD được bảo vệ chống lại phát lại, ngăn chặn và giả mạo. Mỗi CICAM có khả năng phát hiện RSD trên mạng. CAS phải cung cấp CICAM khả năng đóng hoặc mở chức năng phát hiện RSD, nhưng cơ chế chính xác này nằm ngoài phạm vi tiêu chuẩn này và tùy thuộc CAS cụ thể. Nếu nhà khai thác dịch vụ mở chức năng phát hiện RSD, RSD phải có trên mạng và RSD phải được truyền lặp đi lặp lại. Các yêu cầu và định dạng chính xác của RSD được quy định trong Chuẩn cấp giấy phép Cl Plus [37].

CICAM phải đảm bảo rằng nó có các phiên bản mới nhất của RSD, SOCRL và SOCWL.

5.5.4. Thời gian chờ truyền

Chu kỳ thời gian của RSD nên ngắn hơn so với thời gian chờ truyền của nó ra để đảm bảo việc thu. Việc tải SOCRL có thời gian chờ truyền và giá trị này được RSD truyền.

5.5.5. Quá trình tải SOCRL và SOCWL

Việc tải (sử dụng một băng truyền) của SOCRL và SOCWL được thực hiện theo hình 5.8 có tính chất tham khảo và không loại trừ các phương pháp khác. Từng bước của quá trình này được trình bày tóm tắt như sau.

• Bắt đầu (1). Việc tải của RSD có thể bắt đầu sau khi CICAM và máy chủ đã được liên kết thành công.

• Tải RSD (2). CICAM thu được RSD của nhà điều hành dịch vụ.

• Thời gian chờ tải RSD (3). Trong thời gian chờ truyền RSD, thiết bị máy chủ tạm thời bị thu hồi (18). Khi tải về hoàn thành thành công, CICAM xác định xem một SOCRL hay SOCRL và SOCWL nên được tải về.

• Tải SOPKC (4). CICAM tải SOPKC.

• SOPKC không có sẵn (5). Nếu SOPKC không có sẵn hoặc không hợp lệ thì máy chủ tạm thời bị thu hồi (20).

• RSD hợp lệ (6). Bằng cách sử dụng SOPKC, CICAM xác định rằng RSD này là hợp lệ. Xem Chuẩn giấy cấp phép Cl Plus [33] để biết thêm chi tiết.

• Tải SOCRL (7). CICAM so sánh số phiên bản SOCRL trong RSD với số phiên bản của SOCRL được lưu trữ trước đó. Trường hợp RSD này có phiên bản mới hơn, SOCRL này phải được tải về, tương tự đối với SOCWL. Vị trí của băng truyền dữ liệu có chứa SOCRL và SOCWL được lưu trong RSD.

• SOCRL tải time-out (8). Trong thời gian chờ truyền SOCRL máy chủ tạm thời bị thu hồi (18). Khi quá trình tải về hoàn thành, CICAM xử lý SOCRL (7).

• Xử lý SOCRL (9). Khi việc tải về SOCRL đã hoàn thành thành công, CICAM kiểm tra đóng dấu kỹ thuật số của SOCRL. SOCRL này có thể được nhà điều hành dịch vụ hoặc Nguồn gốc tin cậy đóng dấu. Số phiên bản của SOCRL và số phiên bản được quy định tại RSD được kiểm tra so sánh.

Hình 5.8 - Sơ đồ tải về SOCRL và SOCWL

• SOCRL hồ tải về S. ViL hồ tải về SOCRL và SOCWL thành thành công, CICAM kiểm tra đóng dấu kỹ thuật số của SOCRL. SOCRL này có thể được nhà điều hành dịch vụ hoặc Nguồn gốc tin cậy đóng dấu. Số ph

• SOCWL được thông báo trong RSD (11). Nếu không có SOCWL được thông báo trong RSD thì CICAM tiến hành kiểm tra xem máy chủ có trong SOCRL (16).

• Tải SOCWL (12). Nếu một SOCWL được thông báo trong RSD thì nó được tải về.

• Xử lý SOCWL (13). Khi SOCWL đã được tải về thành công, CICAM kiểm tra đóng dấu kỹ thuật số của SOCWL. SOCWL này chỉ có thể được nhà điều hành dịch vụ đóng dấu. Nó cũng kiểm tra xem:

○ Nếu ‘số phiên bản’ thuộc SOCWL bằng ‘số phiên bản’ thuộc RSD.

○ Nếu ‘số phiên bản CRL’ thuộc SOCWL bằng ‘số phiên bản’ thuộc SOCRL.

• SOCWL hợp lệ (14). Các điều kiện sau đây phải được đáp ứng để xác nhận SOCWL:

○ Đóng dấu kỹ thuật số SOCWL trong SOCWL được xác thực

○ ‘Số phiên bản’ thuộc SOCWL bằng ‘số phiên bản’ thuộc RSD

○ ‘Số phiên bản CRL’ thuộc SOCWL bằng ‘số phiên bản CRL’

○ Nếu không, máy chủ tạm thời bị thu hồi (20).

• Thiết bị máy chủ trong SOCWL (15). Trường hợp máy chủ hiện đang liên kết với CICAM được liệt kê trong SOCWL thì các dịch vụ được Cl Plus bảo vệ phải bị bỏ thu hồi (17), nếu không thì kiểm tra SOCRL (16)

• Thiết bị máy chủ trong SOCRL (16). Trường hợp máy chủ hiện đang liên kết với CICAM được liệt kê trong SOCRL thì máy chủ phải bị thu hồi (18), nếu không thiết bị máy chủ không bị thu hồi (17).

• Bỏ thu hồi: CICAM hoạt động hoàn toàn (17). Máy chủ được liên kết với CICAM không bị thu hồi, nó hoặc là trong SOCWL hoặc không được liệt kê trong SOCRL. Bất kỳ thu hồi (tạm thời) hiện có bị loại bỏ.

• Thu hồi: CICAM hoạt động hạn chế (18). Máy chủ được liên kết với CICAM bị thu hồi; tất cả các dịch vụ được Cl Plus bảo vệ vẫn được CA xáo trộn cho đến khi một SOCRL thu được không chứa một đầu vào nào dành cho máy chủ. Trạng thái thu hồi này loại bỏ bất kỳ trạng thái thu hồi tạm thời.

• Thiết bị máy chủ bị thu hồi được cập nhật trong lịch sử liên kết (19). CICAM duy trì một danh sách trong bộ nhớ không thay đổi được của máy chủ đã được liên kết thành công với CICAM. Danh sách này phải được cập nhật:

○ Trường hợp máy chủ trong SOCWL thì đầu vào của nó trong lịch sử liên kết phải được cập nhật bằng cách loại bỏ cờ thu hồi dành cho nhà điều hành dịch vụ hiện tại.

○ Trường hợp máy chủ trong SOCRL thì đầu vào của nó trong lịch sử liên kết phải được cập nhật bằng cách thiết lập cờ thu hồi dành cho nhà điều hành dịch vụ hiện tại.

○ Mỗi máy chủ trong lịch sử liên kết đối với nhà điều hành dịch vụ hiện tại phải được kiểm tra SOCRL (và SOCWL) và cờ thu hồi được điều chỉnh thích hợp.

• Thu hồi tạm thời: CICAM hoạt động hạn chế (20). Khi kết thúc thời gian chờ truyền RSD, thời gian chờ truyền SOCRL, một SOCRL hoặc SOCWL hoặc SOPKC không hợp lệ thì CICAM tạm thời thu hồi máy chủ bằng cách trở thành hoạt động hạn chế. Bất kỳ thu hồi tạm thời bị loại bỏ khi SOPKC hợp lệ, SOCRL hợp lệ (10) và khi một SOCWL hiện tại cũng hợp lệ (14).

5.5.6. Từ chối dịch vụ

Quá trình thu hồi này được CICAM dựa trên việc từ chối dịch vụ và được thực hiện theo hình 5.9 có tính chất tham khảo và không loại trừ các phương pháp khác. Từng bước của quá trình này được trình bày tóm tắt như sau.

Hình 5.9 - Sơ đồ thu hồi bằng cách từ chối dịch vụ

• B- Sơ đ. Sau khi CICAM và máy chủ từ chối dịch vụ các phương pháp khác. Từng bước của quá trình này được trình bày tóm tắt như sau. tạm thời thu hồi máy chủ bằng cách t

• L Sau kh d Sau k. Ngay khi CICAM và máy chủ từ chối dịch vụ các phương pháp khác. Từng bước của quá trình này được trình bày tóm tắt như sau. tạm thời thu hồi máy chủ bằng cách trở thành hoạt động hạn chế. Bất kỳ thu hồi (3).

• Dịch vụ được Cl Plus bảo vệ. CICAM xác định bằng giá trị EMI xem dịch vụ được lựa chọn này là được Cl Plus bảo vệ. Nếu yêu cầu được Cl Plus bảo vệ thì CICAM kiểm tra xem máy chủ không bị thu hồi (4) nếu không dịch vụ được CA bảo vệ có thể được giải xáo trộn (5).

• Thiết bị máy chủ bị thu hồi. CICAM sử dụng lịch sử liên kết để kiểm tra xem máy chủ mà nó liên kết có cờ bị thu hồi (tạm thời). Nếu máy chủ liên kết bị thu hồi thì dịch vụ được CA bảo vệ không được giải xáo trộn nếu không thì dịch vụ được giải xáo trộn (6).

• Dịch vụ được CA giải xáo trộn. Dịch vụ được lựa chọn này được CA giải xáo trộn nhưng không được Cl Plus xáo trộn lại. Dịch vụ không được bảo vệ này được truyền tới máy chủ (7).

• Dịch vụ được CA giải xáo trộn và dịch vụ được Cl Plus xáo trộn lại. Dịch vụ được lựa chọn này là một dịch vụ được Cl Plus bảo vệ và máy chủ liên kết không bị thu hồi, trước tiên, dịch vụ này được CA giải xáo trộn và sau đó được Cl Plus xáo trộn lại. Dịch vụ được Cl Plus bảo vệ được truyền tới máy chủ (7).

• Đầu ra đến thiết bị máy chủ. CICAM có thể truyền dịch vụ được lựa chọn này đến máy chủ liên kết để sử dụng. Dịch vụ này không được mã hóa (bảo vệ CA bị loại bỏ) hoặc được mã hóa (bảo vệ CA bị loại bỏ nhưng bảo vệ Cl Plus được thêm vào).

5.6. Xáo trộn (Giải xáo trộn) nội dung

5.6.1. Xáo trộn mức dòng truyền tải

Để bảo vệ nội dung có giá trị cao, nhà cung cấp dịch vụ có thể lựa chọn để “xáo trộn” (mã hóa) nội dung của các dòng thành phần của dịch vụ. Thiết bị thu sử dụng bộ giải xáo trộn để “giải xáo trộn” (giải mã) các dòng thành phần này để chúng có thể được sử dụng. Bộ giải xáo trộn xác định khi nào để giải mã bằng cách xem xét các bit thuộc Kiểm soát xáo trộn truyền (TSC) trong gói tin TS theo quy định tại Bảng 5.4

Bảng 5.4 - Định nghĩa các bit kiểm soát xáo trộn truyền (TSC)

Hình 5.10 - Quan hệ giữa các thanh ghi của bộ giải xáo trộn và TS

CHÚ THÍCH :

1. Tham chiếu điều 5.7.5 để biết thông tin chi tiết về giao thức làm mới URI.

2. Tham chiếu điều 8.1 để biết thông tin chi tiết về giao thức làm mới mã khóa kiểm soát nội dung.

3. Tham chiếu điều 11.3.1 để biết thông tin chi tiết về các APDU. DĐam ch kho chiếu điều 11.3.1 đ

4. Đối với khoảng thời gian sống của mã khóa, CICAM sẽ xáo trộn lại tất cả các ES dưới sự kiểm soát CC bằng CCK và IV (trong trường hợp lựa chọn AES) giống nhau

Hình 5.11 - Làm mới khóa đôi và truyền URI

Các bộ giải xáo trộn mã khóa kép sử dụng hai thanh ghi để lưu trữ hai mã khóa: thanh ghi đầu tiên có thể chứa mã khóa mà bộ giải xáo trộn hiện đang sử dụng. Trong khoảng thời gian mã khóa đầu tiên này, mã khóa thứ hai có thể được cập nhật với một mã khóa mới dành cho khoảng thời gian mã khóa tiếp theo. Để phân biệt các thanh ghi, các thanh ghi được quy định là thanh ghi mã khóa chẵn và lẻ. Bit TSC trong gói tin TS chỉ ra bộ giải xáo trộn sử dụng thanh ghi mã khóa chẵn hoặc lẻ để giải xáo trộn gói tin TS và chuyển sang thanh ghi tương ứng khi cần thiết. Xem hình 5.10 để biết chi tiết.

Việc làm mới mã khóa chẵn/lẻ được CICAM thông báo trong dữ liệu yêu cầu APDU, máy chủ biết trước thanh ghi của bộ giải xáo trộn nào mà nó phải lưu trữ mã khóa kiểm soát nội dung (CCK) mà CICAM điều khiển nó bắt đầu tính toán. Để xác định xem máy chủ đã thực sự tính toán mã khóa CC và nạp nó vào thanh ghi được yêu cầu (chẵn hoặc lẻ), CICAM và máy chủ đồng bộ với nhau; CICAM khởi tạo một yêu cầu đồng bộ APDU mà máy chủ phải xác nhận. Nếu bộ đếm thời gian làm mới mã khóa hết hạn CICAM phải bắt đầu sử dụng mã khóa CC mới (CCK) và sửa đổi các bit TSC trong phần mào đầu của gói tin TS. Ngay sau khi CICAM thay đổi giá trị TSC, máy chủ phải phát hiện sự thay đổi và chuyển sang thanh ghi mã khóa thay thế. Giao thức URI truyền giá trị URI đến máy chủ. URI chỉ ra những hạn chế của nội dung. Xem hình 5.11 để biết chi tiết.

5.6.1.1. Xáo trộn mức PES

Trường hợp nhà cung cấp dịch vụ sử dụng xáo trộn mức PES đối với các dòng thành phần, tức là các bit PES_scrambling_control của PES_packet là khác không thì bất kỳ việc xáo trộn lại của CICAM phải được áp dụng lại ở mức dòng truyền tải và trường PES_scrambling_control phải được thiết lập là ‘Not Scrambled’.

5.6.2. Định nghĩa bộ xáo trộn/bộ giải xáo trộn

5.6.2.1. Các quy tắc xáo trộn

Tiêu chuẩn này định nghĩa hai bộ xáo trộn dành cho bảo vệ đầu ra dòng TS là DES và AES. Bảng 5.5 mô tả các khả năng bắt buộc của máy chủ và CICAM.

Bảng 5.5: Các khả năng của CICAM và Máy chủ

Định nghĩa của máy chủ SD và HD dành cho các mục đích của tiêu chuẩn này được quy định tại Phụ lục D.

Máy chủ và CICAM thương lượng các khả năng xáo trộn trong quá trình trao đổi giấy chứng nhận. Mỗi thiết bị xác định khả năng xáo trộn thiết bị kia, xem 9.3.9.5. Cả hai thiết bị phải quyết định sử dụng mã hóa nào (xem Bảng 5.6).

Nếu có một liên kết hiện có, tức là phù hợp với các mã khóa xác thực, thì mã hóa được thương lượng trước đây phải được sử dụng (xem Điều 6.3).

Bảng 5.6: Các quy tắc lựa chọn xáo trộn Cipher

Hệ thống kiểm soát nội dung Cl Plus tuân thủ các quy tắc xáo trộn sau đây:

• Các gói TS của dòng truyền tải thành phần của chương trình được lựa chọn mà rõ ràng về phía mạng không được kiểm soát nội dung Cl Plus xáo trộn và phải vẫn là rõ ràng.

• Nội dung đã được hệ thống CA của mạng giải xáo trộn và kiểm soát nội dung Cl Plus cho biết thông qua một URI mang EMI có giá trị là 0x00 không được kiểm soát nội dung Cl Plus xáo trộn lại. Trong trường hợp này các gói tin TS của dòng thành phần thuộc vào chương tình được lựa chọn đã được xáo trộn trên mạng được truyền đến máy chủ một cách rõ ràng.

• Nội dung đã được hệ thống CA của mạng giải xáo trộn và kiểm soát nội dung Cl Plus cho biết thông qua một URI mang EMI có giá trị khác 0x00 được kiểm soát nội dung Cl Plus xáo trộn lại. Trong trường hợp này các gói tin TS của dòng thành phần thuộc vào chương trình được lựa chọn đã được xáo trộn trên mạng được truyền đến máy chủ được kiểm soát nội dung Cl Plus xáo trộn lại.

• Kiểm soát nội dung Cl Plus phải luôn luôn sử dụng các mã hóa xáo trộn giống nhau đối với tất cả các loại nội dung (âm thanh, video hoặc một số thành phần khác của chương trình được lựa chọn) và sử dụng mã hóa cao nhất đã được thương lượng.

• CICAM chỉ được giải xáo trộn và có thể xáo trộn lại, các dòng thành phần đã được thông báo để giải xáo trộn trong CA_PMT theo EN 50221 [7], điều 8.4.3.4.

• CICAM không bắt buộc phải truyền nội dung trên một kênh được mã hóa DES. Tức là nó tùy theo quyết định của nhà khai thác dịch vụ xem có cung cấp nội dung giá trị cao HD (hoặc SD) qua DES và có thể chỉ lựa chọn để cung cấp nội dung đến các thiết bị AES, vô hiệu một cách hiệu quả các thiết bị chỉ có DES đối với các dịch vụ đó.

Ngoài các quy tắc được quy định tại Bảng 5.9, áp dụng các quy tắc xáo trộn của SCTE41 [5], điều 7.1.1. Trong trường hợp xung đột các quy tắc trên được ưu tiên. (Ví dụ như ngoài việc sử dụng DES AES được cho phép và quy định.)

5.6.2.2. Xáo trộn TS với DES

Tải của các gói tin TS có thể được mã hóa bằng DES-56 trong chế độ ECB với các khối dư để lại rõ ràng. Bộ xáo trộn và bộ giải xáo trộn DES tuân thủ SCTE41 [5], Phụ lục B.

Chú ý: Có sự khác biệt trong đánh số bit và byte được sử dụng trong MPEG2 (xem ISO 13818-1 [13]) và Chuẩn DES (xem FIPS 46-3 [2]). Việc ánh xạ hệ thống đánh số được định nghĩa trong tài liệu A/70A, Phụ lục A của ATSC [26].

5.6.2.3. Xáo trộn TS với AES

Tải của các gói tin TS có thể được mã hóa bằng AES-128 trong chế độ CBC với mã khóa CC và thay đổi IV mỗi khoảng thời gian duy trì mã khóa và các khối dư để lại rõ ràng. Tham khảo FIPS 197[4] đối với mã hóa AES-128 và tham khảo ấn phẩm đặc biệt 800-38A của NIST [25] để sử dụng AES-128 trong chế độ CBC.

Mã hóa nội dung dựa trên ATSC A/70A [26], Phụ lục D.3. Phần sau đây mô tả bộ xáo trộn và bộ giải xáo trộn AES dành cho tiêu chuẩn này.

Hình 5.12 chỉ ra định dạng cấp cao của một gói TS (xem ISO 13818-1 [13]).

Hình 5.12 - Gói tin TS

Các gói tin TS bao gồm một mào đầu (màu xám) và trường Tải. Tùy thuộc vào kích thước của Trường thích ứng, độ dài của phần Tải có giá trị từ 0 đến 184 byte. Chỉ phần Tải được xáo trộn. Phần Tải thì được phân mảnh thành các khối 128 bit (16 byte) và chuyển qua cơ chế xáo trộn AES như mô tả dưới đây.

5.6.2.3.1. Xáo trộn

Chức năng mã hóa thường định nghĩa b là văn bản rõ ràng và phiên bản được xáo trộn của nó là s. Chức năng mã hóa AES được trình bày bằng s = E_AES-128-CBC {CCK} (b), trong đó mã khóa kiểm soát nội dung (CCK, được quy định trong điều 8.1.4) được sử dụng để mã hóa/xáo trộn một khối nhị phân b có chiều dài bằng 128 bit (16 byte). Việc mã hóa xử lý b thành một khối có cùng kích thước, s.

Khi văn bản rõ ràng là lớn hơn 128 bit thì nội dung này được mã hóa bằng cách sử dụng AES trong chế độ CBC (tức là Chuỗi mã hóa khối CBC), sử dụng công thức sau đây:

s(m)=E_AES-128-CBC {CCK}[b(m)Ås(m-1)]                                                                     Eq.5.1

Trong đó:

• CCK là mã khóa kiểm soát nội dung

• b (m) đại diện cho khối 128 bit thứ m trong chuỗi, trong đó m = 2..n. Mã hóa khối b(m) hiện tại yêu cầu biết văn bản mã hóa s(m-1) (tức là đầu ra của khối được xáo trộn trước đó).

Chú ý rằng phương trình (5.1) không làm việc đối với m = 1. Đối với khối đầu tiên (tức là m = 1), dữ liệu đối với s(0) không có. Vì vậy việc xác định một Véc-tơ khởi tạo (IV), được sử dụng để tính toán khối xáo trộn đầu tiên s(0) bằng phương trình sau đây là cần thiết:

s(1)=E_AES-128-CBC {CCK}[b(1)ÅIV]                                                                             Eq.5.2

Trong đó:

• CCK là mã khóa kiểm soát nội dung và IV (CIV) là một véc-tơ khởi tạo, theo quy định tại điều 8.1.4.

Véc-tơ thích hợp IV phải được sử dụng khi bắt đầu gói tin tải. Tải dữ liệu của một gói tin TS dài tối đa 184 byte, số khối tối đa để mã hóa bằng AES-128-CBC là 11 (vì khối dư vẫn là rõ ràng 184 * 8/128 được làm tròn thành 11).

Các gói tin TS của tất cả các dòng thành phần được lựa chọn sử dụng mã khóa và véc-tơ khởi tạo giống nhau, có hai trường hợp đặc biệt của các khối dư: các khối ngắn đơn độc và kết thúc. Cả hai khối này vẫn là rõ ràng và không được xáo trộn hay giải xáo trộn.

5.6.2.3.2. Khơn độc và kết thúc.

Giả sử rằng một gói tin TS nào đó có thể được chia thành M khối: { b (1), b (2),...,. b (M)}, thường xảy ra là kích thước của khối cuối cùng nhỏ hơn 128 bit. Trong trường hợp này, b (M) theo định nghĩa là một khối ngắn cuối cùng. Xem hình 5.13 để biết chi tiết.

Hình 5.13 - Xáo trộn dữ liệu và khối ngắn cuối cùng.

5.6.2.3.3. Kh Xáo trộn dữ liệu

Trường hợp thứ hai, khối ngắn đơn độc, xảy ra khi gói tin TS được mã hóa chỉ có một khối b (1) và kích thước của nó nhỏ hơn 128 bit. Xem hình 5.14 để biết chi tiết.

Hình 5.14 - "Xáo trộn" khối ngắn đơn độc

5.6.2.3.4. Gi"Xáo trộn"

Tương tự như xáo trộn ở trên, chức năng giải mã AES được trình bày bằng b = D _AES-128-CBC {CCK} (s), trong đó mã khóa kiểm soát nội dung (CCK, được quy định tại điều 8.1.4) được sử dụng để giải mã/giải xáo trộn một khối nhị phân s có chiều dài bằng 128 bit (16 byte). Quá trình giải mã s thành một khối b có cùng kích thước.

Khi khối được giải mã lớn hơn 128 bit thì nội dung được giải mã bằng cách sử dụng AES-128 trong chế độ CBC sử dụng công thức sau đây:

b(m ) = E _{AES - 128 - CBC} {CCK} [s(m)] Å s(m-1)                                                            Eq.5.3

Trong đó:

• CCK là mã khóa kiểm soát nội dung.

• s (m) đại diện cho khối 128 bit thứ m trong chuỗi, trong đó m = 2..n. Giải mã khối s(m) hiện tại yêu cầu biết văn bản mã hóa s(m-1) (tức là khối được giải xáo trộn trước đó).

Phương trình 5.3 không làm việc đối với m = 1. Để khởi tạo, công thức sau được sử dụng:

b(1)=D_AES-128-CBC {CCK} [s(1)] Å IV                                                                        Eq . 5.4

Trong đó:

• CCK là mã khóa kiểm soát nội dung và IV (CIV) là một véc-tơ khởi tạo được quy định tại điều 8.1.4.

Hình 5.15 - Giải xáo trộn dữ liệu và khối ngắn cuối cùng.

Hình 5.16 - "Giải xáo trộn" khối ngắn đơn độc

5.7. Thực hiện kiểm soát sao chép nội dung

5.7.1. Định nghĩa URI

Nhà cung cấp nội dung và nhà phân phối nội dung quy định các giá trị thông tin các quy tắc sử dụng (URI) đối với mỗi chương trình (ví dụ như dịch vụ hoặc sự kiện) ngoại tuyến. Hệ thống CA cung cấp URI một cách an toàn từ thiết bị đầu cuối của mạng đến CICAM. CICAM truyền URI đến máy chủ sử dụng giao thức SAC. Máy chủ sử dụng URI để kiểm soát việc tạo ra bản sao, mã hóa kiểm soát sao chép đối với đầu ra tương tự, kích hoạt hình ảnh bị hạn chế và để thiết lập các thông số kiểm soát sao chép đối với các đầu ra của máy chủ.

5.7.2. URI liên kết với nội dung

Hệ thống CA phải liên kết URI với nội dung một cách an toàn, tức là một dịch vụ/sự kiện MPEG cụ thể. URI được liên kết với dịch vụ được lựa chọn thông qua số chương trình MPEG2 16-bit được quy định tại chuẩn ISO 13818-1 [13].

Tất cả các PID thuộc về một chương trình (như đã nêu trong PMT) chỉ có liên kết với một URI.

Chú ý: nội dung (tức là các sự kiện MPEG2) được đề cập đến trong tiêu chuẩn này không được sử dụng số chương trình có giá trị là 0 (không).

5.7.3. Truyền URI - từ Thiết bị đầu cuối đến CICAM

URI có thể được truyền từ thiết bị đầu cuối DVB đến CICAM theo những cách không được tiết lộ. Một ví dụ là để truyền thông tin URI thực và thông tin số chương trình trong một bản tin EMM hoặc ECM được hệ thống CA của mạng bảo vệ. Cơ chế truyền chính xác được sử dụng để truyền dữ liệu URI từ thiết bị đầu cuối đến CICAM nằm ngoài phạm vi tiêu chuẩn này.

5.7.4. Truyền URI - từ CICAM đến máy chủ

Khi CICAM thu được dữ liệu URI thì dữ liệu này phải được truyền từ CICAM đến máy chủ thông qua định dạng bản tin URI. Định dạng bản tin URI được mô tả trong điều 5.7.5.2.

CICAM chuyển URI đến máy chủ dưới các điều kiện hoạt động khác nhau bằng cách sử dụng phương pháp sau đây:

• Khi xem nội dung trực tiếp, sử dụng phương thức truyền URI và giao thức thừa nhận (Xem phần 11.3.3.6)

• Khi ghi lại nội dung với EMI = 1,1, sử dụng giao thức Trao đổi Giấy phép (Xem phần 11.3.4.1)

• Khi chơi lại nội dung đã ghi mà trong đó có một giấy phép, sử dụng giao thức Trao đổi Giấy phép chơi lại (Xem phần 11.3.4.2)

Một Cl Plus CICAM sẽ không gửi truyền URI trừ khi nó đã được lựa chọn bởi các máy chủ cho việc giải xáo trộn các dịch vụ hiện tại.

Ngay lập tức sau khi bật nguồn điện hoặc thay đổi kênh tới một dịch vụ kiểm soát CAS, máy chủ phải sử dụng các giá trị URI mặc định ban đầu dưới đây.

Bảng 5.7: Giá trị mặc định cho Cl Plus URI phiên bản 1

Bảng 5.8: Giá trị mặc định cho Cl Plus URI phiên bản 2

Sau khi thiết lập URI mặc định ban đầu này, máy chủ phải bắt đầu bộ đếm thời gian 10 giây. Nếu máy chủ chưa hoàn thành thành công giao thức truyền URI khi bộ đếm thời gian đạt đến mười (10) giây, máy chủ phải thay đổi các giá trị URI sang giá trị lỗi giống như giá trị mặc định ban đầu, ngoại trừ bit ICT được thiết lập là 0b1: trong trường hợp đó, máy chủ phải áp dụng nén hình ảnh nếu bit ICT đã được thiết lập là một. URI sau thời gian chờ được gọi là URI mặc định cuối cùng.

Một thiết bị tuân thủ Cl Plus phải hỗ trợ URI phiên bản 0x01 và 0x02 và có thể bỏ qua các phiên bản URI khác. Bất kỳ phiên bản URI tương lai phải kết hợp các bit EMI và APS được định nghĩa trong phiên bản 0x01.

Các phiên bản URI tương lai không được ghi đè lên các bít hiện có trong phiên bản URI 0x01. Điều này có nghĩa rằng các phiên bản URI tương lai có thể thêm những hạn chế nội dung bổ sung mà thiết bị trong tương lai có thể hỗ trợ, miễn là những hạn chế nội dung không làm các khả năng giới hạn ít hơn. Các thiết lập của các bit EMI, APS và ICT phải luôn luôn được giữ nguyên.

Máy chủ được thiết lập để lưu giữ URI trong khi đồng nhất tới một dịch vụ nào đó mà không phụ thuộc vào trạng thái tín hiệu, ví dụ: Nếu tín hiệu bị mất do ngắt kết nối ăng ten hoặc tín hiệu giảm xuống dưới mức yêu cầu tối thiểu thì bất kỳ URI nào đã nhận trước đây sẽ vẫn có hiệu lực.

5.7.5. Giao thức làm mới URI

Bản tin URI được truyền từ CICAM đến máy chủ được SAC bảo vệ (xem điều 7). CICAM và máy chủ phải cùng nhau thực hiện các bước dưới đây một lần đối với từng lần truyền URI. Bất kỳ sự thất bại của các bước được mô tả dưới đây cũng dẫn đến việc truyền URI thất bại. Nếu giao thức không được hoàn thành thành công trước khi thời gian chờ hết hạn một giây thì CICAM phải vô hiệu việc CA giải xáo trộn và máy chủ phải thiết lập URI sang giá trị URI mặc định cho đến khi giao thức làm mới URI hoàn thành thành công.

CICAM phải gửi một URI đến máy chủ chỉ sau khi CICAM và máy chủ đã được liên kết thành công và thương lượng một mã khóa kiểm soát nội dung chung (CCK). CICAM phải bắt đầu việc truyền URI đến máy chủ trên dịch vụ được CA kiểm soát ngay sau khi:

• Máy chủ gửi một ca_pmt mới đến CICAM, hoặc

• Số chương trình thay đổi trên một 'kênh' được dò kênh, hoặc

• bất kỳ thay đổi trong các bit URI trong một chương trình, hoặc

• bất kỳ thay đổi trong các giá trị ID của gói tin MPEG (PID) mà CICAM đang giải xáo trộn. Quá trình chính xác được giải thích trong hình 5.17.

CHÚ THÍCH

1. Lưu đồ này không chỉ ra rằng bất kỳ hành vi nào (không) được đồng bộ/ được chia khối.

2. Các bước 1 và 2 được trình bày nhưng nằm ngoài phạm vi của tiêu chuẩn này.

3. Tham chiếu hình 5.15 để biết tổng quan về giao thức làm mới URI và giao thức làm mới CCK.

Hình 5.17 - Giao thức làm mới URI (tham khảo)

Quá trình này được mô tả trong bảng 5.9:

Bảng 5.9: Hành vi giao thức URI (quy định)

5.7.5.1. Giao thức tuân theo danh sách hợp lệ S

Hình 5.18 - Giao thức thương lượng phiên bản URl

Thương lượng phiên bản URI được thực hiện một lần sau khi khởi tạo (lại) SAC. CICAM gửi một bản tin tới máy chủ yêu cầu các phiên bản URI nó có khả năng hỗ trợ. Máy chủ trả lời bằng một bitmask của các phiên bản URI mà nó hỗ trợ. Tham khảo điều 11.3.3.7.

CICAM phải xác định các tổ hợp phù hợp của các phiên bản URI được cả CICAM và máy chủ hỗ trợ. CICAM quyết định phiên bản URI nào sử dụng, quá trình chính xác này nằm ngoài phạm vi tiêu chuẩn này.

Nếu không tìm thấy tổ hợp phù hợp của các URI phiên bản nào ngoài phiên bản mặc định, hệ thống phải sử dụng phiên bản URI mặc định.

5.7.5.2. Nếu không tìm thấy tổ hợp

Cú pháp bản tin URI phiên bản 1 được quy định tại Bảng 5.10, cú pháp phiên bản 2 được thể hiện trong Bảng 5.11.

Bảng 5.10: Cú pháp bản tin URI phiên bản 1

Bảng 5.11: Cú pháp bản tin URI phiên bản 1

5.7.5.3. Mã hóa và ngtrol_info rl_copy_contr

protocol_version: tham số này chỉ ra phiên bản của định nghĩa URI và được định nghĩa trong Bảng 5.12:

Bảng 5.12: Giá trị cho phép của protocol_version

aps_copy_control_info: tham số này mô tả các bit của hệ thống bảo vệ tương tự (APS) trong đó xác định các thiết lập bảo vệ sao chép tương tự được sử dụng trên đầu ra tương tự, như được giải thích trong Bảng 5.13:

Bảng 5.13: Giá trị cho phép của aps_copy_control

emi_copy_control_info: tham số này mô tả các bit chỉ số chế độ mã hóa (EMI). Hệ thống Cl Plus phải sử dụng các bit EMI để thực hiện các quyền kiểm soát sao chép đối với các đầu ra kỹ thuật số và tương tự như được giải thích ở Bảng 5.14:

Bảng 5.14: Giá trị cho phép của emi_copy_control_info

ict_copy_control_info: tham số này mô tả bit ICT. Máy chủ phải sử dụng bit ICT để kiểm soát chất lượng hình ảnh bị nén đối với các đầu ra thành phần tương tự HD được giải thích trong Bảng 5.15.

Bảng 5.15: Giá trị cho phép của ict_copy_control_info

rct_copy_control_info: tham số này mô tả bit RCT. Máy chủ phải sử dụng bit RCT để kích hoạt kiểm soát phân phối lại về nội dung được kiểm soát khi giá trị RCT được đặt thành một (1) kết hợp với các bit EMI được thiết lập một giá trị là không, không (0,0), để thông báo sự cần thiết kiểm soát phân phối lại để khẳng định về kiểm soát nội dung mà không phải khẳng định kiểm soát sao chép số như được giải thích trong Bảng 5.16.

Bảng 5.16: Giá trị cho phép của rct_copy_control_info

dot_copy_control_info: tham số này mô tả bit DOT. Máy chủ phải sử dụng bit DOT để kiểm soát các đầu ra video tương tự như được giải thích trong Bảng 5.17. Khi các bit EMI là (1,1) CICAM có thể thiết lập bit dot_copy_control_info một giá trị khác không (0) để ngăn cấm máy chủ đưa ra nội dung video tương tự.

Bảng 5.17: Giá trị cho phép của dot_copy_control_info

rl_copy_control_info: trường này mô tả giới hạn duy trì việc ghi chép và/hoặc thời gian chuyển nội dung từ thời gian mà nó được giữ lại. Hình 5.19 chỉ ra cách áp dụng giới hạn duy trì này. Các bit rl_copy_control_info mặc định trong bản tin URI phải luôn luôn được lấp đầy bằng giá trị giới hạn duy trì mặc định (0x00) trừ khi các bit EMI được thiết lập giá trị là một, một (1,1). Khi EMI là (1,1) CICAM có thể thiết lập các bit rl_copy_control_info một giá trị khác không 0x00 (zero) để ghi đè giới hạn duy trì mặc định 90 phút này, các giá trị khác có thể thông báo một giới hạn duy trì tính theo giờ hoặc ngày. Khi EMI là (1,1) và CICAM đã không nhận được thông tin từ mạng thì giá trị rl_copy_control_infovalue mặc định trong bản tin URI được làm đầy bằng giá trị giới hạn duy trì mặc định 0x00.

Hình 5.19 - Ví dụ về giới hạn thời gian duy trì 90 phút

Bảng 5.18 - Các giá trị URI phiên bản 1 cho phép đối với rl_copy_control_info

Bảng 5.19 - Các giá trị URI phiên bản 2 cho phép đối với rl_copy_control_info

Nếu CICAM nhận rl_copy_control_infofrom từ mạng mà là phiên bản URI cao hơn so với phiên bản mà máy chủ có thể hỗ trợ, CICAM phải sử dụng giá trị rl_copy_control_info cao nhất có khả năng đối với phiên bản URI phù hợp.

Ví dụ:

rl_copy_control_info của mạng = 0xf0 (238 ngày)

Máy chủ có URIv2 rl_copy_control_info = 0xf0 (238 ngày)

Máy chủ có URIv1 rl_copy_control_info = 0x3f (61 ngày)

5.8. Các chế độ hoạt động

Máy chủ và CICAM đáp ứng tiêu chuẩn này phải hoàn toàn tương thích với giao diện chung được quy định tại EN 50221 [7] và TS 101 699 [8]. Một DVB CICAM được ghép vào một máy chủ Cl Plus phải hoạt động bình thường. Máy chủ phải nhận ra rằng Cl là DVB Cl và sử dụng các tài nguyên của DVB Cl. Nếu Cl Plus CAM được ghép vào một máy chủ DVB Cl, máy chủ phải nhận ra máy chủ là một thiết bị DVB Cl hợp lệ và hoạt động bình thường. Bảng 5.21 mô tả các chế độ hoạt động khác nhau của CICAM và máy chủ.

Bảng 5.20: Các chế độ hoạt động của CICAM và Máy chủ

5.8.1. Máy chủ hoạt động với nhiều CICAM

Một máy chủ tuân thủ Cl Plus có thể hỗ trợ tối đa 5 khe Cl Plus. Mỗi khe có thể ghép một DVB CICAM hoặc một Cl Plus CAM. Tất cả các kết hợp là được cho phép. Có thể có thêm khe cắm bổ sung chỉ hỗ trợ DVB CI.

Đối với máy chủ có một bộ dò kênh duy nhất, TS phải được truyền nối tiếp qua từng CICAM được ghép vào máy chủ, xem Hình 5.20. Đối với các máy chủ có hai bộ dò kênh thì không cần truyền nối tiếp mà tùy thuộc vào nhà sản xuất máy chủ để định tuyến hai TS này một cách phù hợp.

Hình 5.20 - Truyền nối tiếp TS qua các CICAM

Máy chủ và CICAM đơn sẽ phải giải xáo trộn một dịch vụ và có khả năng tái xáo trộn nó tùy theo đặc điểm kỹ thuật này. Một tình huống khi mà hai hay nhiều mô đun giải xáo trộn một dịch vụ khác của TS có thể được tùy chọn thực hiện bởi máy chủ và CICAM.

Khi một CICAM được cắm vào, máy chủ bắt đầu giao tiếp với CICAM như mô tả trong EN 50.221 [7]. CICAM mở phiên cần thiết cho hoạt động của nó. Máy chủ nhớ số thứ tự của khe cắm tương ứng cho mỗi phiên mở cửa. Khi có nhiều hơn một CICAM có mặt trong quá trình khởi của máy chủ, máy chủ có thể khởi tạo các CICAMs từng cái một, tức là nó có thể trì hoãn khởi tạo CICAM tiếp theo cho đến khi CICAM trước đó là hoàn thành.

Lúc khởi động, một CICAM đầu tiên thực hiện việc xác minh khóa xác thực của máy chủ (AKH). Nếu thành công, Giao thức xác thực hoàn toàn có thể được bỏ qua. Điều 6.3 giải thích thủ tục này. Khi một CICAM cố gắng mở một phiên đến một tài nguyên, máy chủ có thể bận vì nhiều lý do. Một CICAM phải chấp nhận một phản hồi "tài nguyên bận" khi nó cố gắng mở một phiên.

Một Cl Plus CAM không được gửi URI trừ khi nó đã được máy chủ lựa chọn cho giải xáo trộn dịch vụ hiện tại.

Các CICAM phải hỗ trợ các máy chủ có nhiều khe cắm dùng chung địa chỉ, dữ liệu và các đường điều khiển. Mỗi CICAM phải kiểm tra chân Cho phép thẻ số 1 (CE1 #) trước khi sử dụng bất kỳ tín hiệu nào trên bus dùng chung.

Khi một mô-đun yêu cầu tính toán lại mã khóa CC trong khi máy chủ đang chạy một tính toán lại mã khóa CC đối với một mô-đun khác thì máy chủ có thể chỉ ra rằng nó đang bận.

Khi một CICAM gặp dữ liệu của TS mà không hiểu được thì nó phải chuyển tiếp không làm thay đổi TS này.

5.8.2. CICAM duy nhất với sự hỗ trợ của nhiều hệ thống CA

5.8.2.1. Giới thiệu

Phần này định nghĩa cách một CICAM duy nhất với nhiều hệ thống CA và nhiều bộ đọc thẻ thông minh phải hoạt động theo các yêu cầu Cl Plus.

5.8.2.2. Giấy chứng nhận thiết bị CICAM

CICAM chỉ được có một Giấy chứng nhận thiết bị; Giấy chứng nhận này không phụ thuộc vào số lượng các hệ thống CA được CICAM hỗ trợ.

5.8.2.3. Làm mới CCK

CCK độc lập với hệ thống CA; Hệ thống CA có trách nhiệm kiểm soát việc làm mới CCK. Khi khởi tạo CICAM, CCK này được tạo ra như được quy định tại điều 8.1.4.

Chỉ có một hệ thống CA được hoạt động tại một thời điểm, chỉ có hệ thống CA đang hoạt động kiểm soát lệnh làm mới CCK. Việc làm mới CCK được quy định tại điều 8.1.2.

5.8.2.4. Thu hồi máy chủ

Thu hồi máy chủ chỉ được hệ thống CA đang hoạt động thực hiện.

5.9. Tổng quan xác thực

Tiêu chuẩn này yêu cầu xác thực lẫn nhau giữa máy chủ và CICAM. Trước khi CICAM có thể bắt đầu giải xáo trộn nội dung được CA bảo vệ, máy chủ và CICAM phải thông qua một thủ tục xác thực, đó là hoàn thành thành công các nội dung sau:

• CICAM yêu cầu và máy chủ cung cấp chuỗi của giấy chứng nhận của nó. CICAM kiểm tra đóng dấu của giấy chứng nhận thiết bị máy chủ có chứa HOST_ID và CICAM kiểm tra đóng dấu giấy chứng nhận thương hiệu của máy chủ.

• Máy chủ yêu cầu và CICAM cung cấp chuỗi của giấy chứng nhận của nó. Máy chủ kiểm tra đóng dấu của giấy chứng nhận thiết bị CICAM có chứa CICAM_ID và máy chủ kiểm tra đóng dấu của giấy chứng nhận thương hiệu của CICAM.

• CICAM và máy chủ chứng minh chúng có mã khóa riêng tương ứng với mã khóa công khai được nhúng trong giấy chứng nhận bằng cách đóng dấu một mã khóa công khai DH, cùng với dữ liệu giao thức khác, và gửi nó đến thiết bị kia để xác nhận đóng dấu.

• Nhà cung cấp dịch vụ kiểm tra xem HOST_ID và CICAM_ID được lấy từ các giấy chứng nhận có được bao gồm trong SOCRL không khi trong chế độ đăng ký dịch vụ, xem điều 5.4.2.

• CICAM và máy chủ chứng minh rằng họ có thể đưa ra được mã khóa xác thực.

Quá trình này được mô tả chi tiết trong điều 6.

Tùy chọn, CICAM có thể nhận được bản tin xác nhận từ nhà điều hành dịch vụ, liệt kê các ID của thiết bị từ bản tin RMR trong chế độ đăng ký dịch vụ. Hệ thống CA phải cung cấp bản tin này một cách an toàn.

Khi nhận được bản tin này, máy chủ và CICAM có thể tiếp tục quá trình xác thực miễn là cả hai điều kiện sau đây là hợp lệ:

• HOST_ID được xác nhận phù hợp với HOST_ID trong giấy chứng nhận thiết bị máy chủ X.509 được xác thực.

• CICAM_ID được xác nhận phù hợp với CICAM_ID trong giấy chứng nhận thiết bị CICAM X.509 được xác thực.

Việc thực hiện của hệ thống CA đối với việc này nằm ngoài phạm vi của tiêu chuẩn này.

Cơ chế xác thực lẫn nhau dựa trên Diffie-Helman (DH). Xem PKCS # 3 [31] để biết chi tiết về DH. Giao thức xác thực Cl Plus sử dụng một giao thức thông qua 3, được áp dụng cho thuật toán DH chuẩn để thỏa thuận mã khóa. Diễn giải đơn giản của giao thức thông qua 3 của DH được đưa ra trong hình 5.21.

Hình 5.21: Quy trình thông qua 3 của Diffie-Hellman

Lưu ý rằng cả hai phía đều tính toán một mã khóa riêng DH. Mỗi phía tính toán mã khóa bắt đầu với một cặp giá trị riêng khác nhau (ví dụ như x và y) và đưa ra cùng một mã khóa mật giống nhau (mã khóa riêng DH).

Một số phương pháp được thực hiện để bảo vệ các thông số DH này khi truyền giữa CICAM và máy chủ:

• CICAM bắt đầu trao đổi bằng cách gửi một nonce đến máy chủ. Nonce này được một giao thức hoàn toàn truyền và được sử dụng trong các đóng dấu để trao đổi tham số trong giao thức này.

• CICAM và máy chủ phải trao đổi lẫn nhau các giấy chứng nhận thiết bị và thương hiệu được lưu trong chúng do ROT tạo ra. Máy chủ phải kiểm tra đóng dấu của giấy chứng nhận thiết bị CICAM.

• CICAM và máy chủ phải trao đổi lẫn nhau các thông số của giao thức được bảo vệ bằng đóng dấu bằng cách sử dụng khuôn khổ mã khóa riêng/công khai từ các giấy chứng nhận. Phía gửi phải tạo ra một đóng dấu trên tất cả các các thông số của giao thức được trao đổi bằng cách sử dụng mã khóa riêng của nó và máy chủ phải kiểm tra xác nhận đóng dấu bằng cách sử dụng mã khóa công khai của thiết bị phía còn lại thu được từ giấy chứng nhận của nó.

Xem điều 6 để biết chi tiết về các cơ chế xác thực hợp lệ.

5.10. Trao đổi giấy phép nội dung

Khi một mục của nội dung được ghi lại có URI với EMI = "1,1", CICAM có thể cung cấp cho một giấy phép tại thời điểm ghi lại. Máy chủ phải kết hợp giấy phép này với mục của nội dung để lấy thời gian ghi lại. Nếu có giấy phép dành cho một mục của nội dung thì giấy phép này có thể được CICAM kiểm tra khi nội dung này được phát lại để xác định xem máy chủ vẫn có quyền được sử dụng nội dung. Việc kiểm tra giấy phép nội dung này yêu cầu CICAM và máy chủ truyền các giấy phép cho nhau qua giao diện chung một cách an toàn. Khi ghi lại thì giấy phép được CICAM cung cấp chứa dữ liệu cụ thể CAS được máy chủ lưu và được kết hợp với nội dung được ghi lại. Khi phát lại nội dung được ghi lại thì giấy phép được kết hợp này được truyền lại cho CICAM đã tạo ra giấy phép mà không có bất kỳ sự thay đổi. CICAM kiểm tra giấy phép này và trả về trạng thái phát lại cùng với một giấy phép mới và phát lại URI thay thế giấy phép nội dung hiện có. Máy chủ được yêu cầu trả lại giấy phép cho CICAM đã cấp giấy phép này, máy chủ sử dụng CICAM_ID để xác định CICAM được sử dụng để ghi lại và sau đó phát lại.

Các giấy phép luôn luôn được trao đổi thông qua SAC sử dụng cc_sac_data_req và cc_sac_data_cnf APDU, xem điều 11.3.1.3 và 11.3.1.4.

5.10.1. Giao thức khởi tạo ghi lại

Máy chủ thông báo bắt đầu ghi lại một dịch vụ được CA bảo vệ CA cho CICAM bằng giao thức khởi tạo ghi lại sử dụng SAC, xem điều 11.3.4.4 để biết chi tiết giao thức. Việc trao đổi này thông báo cho CICAM chế độ hoạt động hiện tại của máy chủ và tùy chọn cho phép máy chủ cung cấp CICAM PIN. CICAM có thể lưu trữ CICAM PIN dành cho ghi lại tự động hoặc tạm dừng. CICAM PIN chỉ phải được sử dụng để cho phép ghi lại không bị gián đoạn khi một sự kiện cha mẹ kiểm soát trong tương lai có thể xảy ra. CICAM PIN không được sử dụng để thực hiện việc kiểm soát của cha mẹ đối với việc phát lại và xem trực tiếp mà người sử dụng phải được yêu cầu nhập CICAM PIN bằng MMI.

Máy chủ có thể thiết lập giao thức Khởi tạo ghi lại trên một dịch vụ FTA với giả định rằng dịch vụ có thể chuyển thành dịch vụ được CA bảo vệ sau. Các CICAM không nên đợi một giao thức khởi tạo ghi lại khác tại bất kỳ trao đổi nào trong tương lai giữa FTA và CA được bảo vệ.

5.10.2. Trao đổi giấy phép nội dung đối với việc ghi lại

Nếu giấy phép được yêu cầu có liên kết với một mục của nội dung thì khi bắt đầu ghi lại, CICAM gửi cho máy chủ một giấy phép bằng cách sử dụng SAC. Quá trình trao đổi giấy phép này sử dụng giao thức SAC trao đổi giấy phép từ CICAM đến máy chủ, xem điều 11.3.4.1 để biết cụ thể hơn.

5.10.3. Trao đổi giấy phép nội dung đối với việc kiểm tra

Máy chủ có thể xác định trạng thái hiện tại của một giấy phép nội dung liên kết với việc ghi lại bằng cách sử dụng giao thức SAC kiểm tra giấy phép, xem điều 11.3.4.3. Máy chủ phải gửi bản tin này đến CICAM đã cấp giấy phép này. Giao thức kiểm tra giấy phép chỉ cung cấp thông tin của máy chủ mà không được sử dụng để đánh giá quyền phát lại.

CICAM trả lời giấy phép kiểm tra bằng thông tin trạng thái của giấy phép này. Thông tin trạng thái này cung cấp thông tin về tình trạng sẵn có của nội dung và có thể được sử dụng khi hiển thị một thư mục ghi lại. Thông tin trạng thái này bao gồm một trường 8-bit play_count có chứa số lượt phát còn lại mà người sử dụng được hưởng.

5.10.4. Trao đổi giấy phép nội dung phát lại

Khi phát lại nội dung có giấy phép liên kết thì máy chủ phải gửi giấy phép này đến CICAM ghi lại nội dung gốc này để đánh giá. Giấy phép này được gửi đến CICAM một cách an toàn trên SAC sử dụng giao thức giấy phép phát lại, xem điều 11.3.4.2. CICAM này xử lý giấy phép này để thiết lập nếu nó vẫn có quyền để phát lại nội dung này. Một giấy phép mới và URI được trả lại cho máy chủ để thay thế bản gốc trong trường hợp thông tin đã thay đổi, ví dụ như play_count. Việc trao đổi giấy phép trên giao thức phát lại được thực hiện song song trong khi đang phát lại nội dung để đảm bảo rằng việc bắt đầu phát lại không bị trì hoãn. Nếu trả lời của giấy phép phát lại không là OK, hoặc trả lời kéo dài hơn 10 giây thì phát lại phải bị dừng lại.

URI mà đính kèm với giấy phép trong Giao thức trao đổi giấy phép nội dung phát lại sẽ được áp dụng ngay lập tức.

5.10.5. Giấy phép nội dung và quá trình chế độ tạm dừng (Timeshift)

Máy chủ không cần phải lưu trữ hoặc trao đổi các giấy phép nội dung khi ghi đệm nội dung cho chế độ tạm dừng, ví dụ như tạm dừng tường thuật trực tiếp (90 phút duy trì). Tuy nhiên, nếu máy chủ sau đó thay đổi các nội dung đã ghi đệm vào một bản ghi, nó phải kết hợp các giấy phép nhận được với các mục nội dung cho toàn bộ thời gian của bản ghi.

LƯU Ý: Điều này có nghĩa rằng trong quá trình chế độ tạm dừng diễn ra, cho phép chuyển đổi các bộ đệm chế độ tạm dừng vào một bản ghi thì sau đó tất cả các giấy phép nội dung đã nhận được trong khoảng thời gian nội dung lưu đệm phải được giữ lại cho đến khi nội dung đệm không còn chuyển đổi thành một bản ghi.

5.10.6. Thỏa thuận dừng ghi (Protocol Record Stop Protocol)

Máy chủ phải đánh dấu kết thúc của một bản ghi bằng cách dùng Thỏa thuận dừng ghi sử dụng SAC, xem điều 11.3.4.6. Với mỗi Thỏa thuận dừng ghi cho một program_number cụ thể, máy chủ phải thi hành một Thỏa thuận dừng ghi tương ứng. Ví dụ: Khi chuyển kênh, Máy chủ sẽ gửi một Thỏa thuận dừng ghi cho dịch vụ hiện tại, khởi tạo đồng bộ đến một vị trí mới và sau đó gửi Thỏa thuận dừng ghi cho dịch vụ mới.

5.11. Kiểm soát của cha mẹ

Đối với dịch vụ FTA, việc xác định độ tuổi phù hợp với nội dung chương trình có thể được thực hiện thông qua nhận diện mô tả của cha mẹ khi sử dụng DVB. Máy chủ có thể tùy chọn cung cấp một cơ chế để:

• Thiết lập việc đánh giá độ tuổi tối đa đối với nội dung có yêu cầu nhập mã PIN trước khi xem.

• Việc nhập mã PIN sẽ cho phép có các ngoại lệ đối với giới hạn này. Theo mục đích của tiêu chuẩn này, PIN này sẽ được gọi là PIN của máy chủ.

Đối với dịch vụ được CA bảo vệ, việc đánh giá độ tuổi có thể được gửi qua hệ thống CA hoặc trong dòng truyền tải bằng cách sử dụng nhãn DVB parental_rating_descriptor. Đối với các dịch vụ được CA bảo vệ, việc đưa ra kiểm soát của cha mẹ nằm ngoài phạm vi tiêu chuẩn này và được CAS và/hoặc CICAM xác định. CICAM có thể cung cấp một menu chương trình để thiết lập mã PIN cho phép một ngoại lệ. Theo mục đích của tiêu chuẩn này, mã PIN này được gọi là CICAM PIN. Phương pháp chính xác được sử dụng để cung cấp việc đánh giá độ tuổi trong trường hợp này nằm ngoài phạm vi của tiêu chuẩn này.

Tiêu chuẩn này bổ sung thêm các tính năng đối với tài nguyên kiểm soát nội dung để cho phép hai hệ thống kiểm soát của cha mẹ tiềm năng này được xử lý như một hệ thống nhằm thuận tiện cho người sử dụng. Việc kiểm soát của cha mẹ đối với dịch vụ được CA bảo vệ được xử lý như bình thường tùy thuộc vào các khả năng của CICAM PIN. CICAM có thể thông báo cho máy chủ đánh giá độ tuổi tối thiểu mà máy chủ bắt đầu để xử lý việc quản lý mã PIN, cho phép máy chủ phát huy việc kiểm soát của cha mẹ khi việc đánh giá của máy chủ được thiết lập để một mức độ thấp hơn so với việc đánh giá này của CICAM. Đối với các dịch vụ FTA khi máy chủ xác định rằng nội dung hiện tại có một đánh giá độ tuổi vượt quá ngưỡng tuổi của người sử dụng thì máy chủ có thể chuyển việc kiểm soát nhập mã PIN sang CICAM bằng một bản tin cc_PIN_MMI_req () có chứa mã PIN FTA của máy chủ (phụ thuộc vào các khả năng của CICAM PIN được thông báo). Sau đó, CICAM tạo ra một MMI hướng dẫn người sử dụng nhập mã PIN. CICAM so sánh PIN được nhập với CICAM PIN và mã PIN của máy chủ được truyền trong bản tin và nếu người sử dụng nhập mã PIN phù hợp với một trong hai mã PIN trên thì nội dung được phép xem.

Trong quá trình xem bình thường, người sử dụng có thể được yêu cầu nhập mã PIN để tiếp tục xem một dịch vụ hoặc sự kiện. Điều này có thể xảy ra khi lựa chọn dịch vụ hoặc lúc bắt đầu xem một sự kiện mới. Trong quá trình xem sự kiện bình thường, người xem sẽ nhập mã PIN chính xác và tiếp tục theo dõi các dịch vụ hoặc sự kiện. Video và âm thanh không được có cho đến khi nhập đúng mã PIN.

Trong quá trình ghi lại hoặc đang tạm dừng nội dung được CA bảo vệ, các hành vi nói trên sẽ gây ra các khoảng thời gian trống không thể chấp nhận khi nội dung này không được giải xáo trộn để ghi lại và do đó không thể xem được trong quá trình phát lại. Tiêu chuẩn này quy định một cơ chế theo đó máy chủ truyền PIN của nó trong cc_Record_Start () APDU mà CICAM nên lưu trữ trong trường hợp nó được yêu cầu trong quá trình ghi lại. Để đảm bảo rằng cơ chế này không được lạm dụng CICAM phải xóa tất cả các mã PIN được lưu trữ khi đến phần cuối của việc ghi lại này.

Trong phạm vi của tiêu chuẩn này, mã PIN của máy chủ và CICAM được giả định là số chữ số từ 0 đến 9 và sẽ không quá 8 chữ số.

Trong tình huống cha mẹ kiểm soát nội dung AV, các thông tin liên quan đến tình huống này có thể được hiển thị cho người xem. Ví dụ: hiển thị "AV blanking" được hiểu rằng các máy chủ sẽ vô hiệu hóa trình bày của âm thanh, video, phụ đề, vv

Máy chủ phải tuân theo các quy tắc kiểm soát của cha mẹ được định nghĩa trong Thỏa thuận cấp phép tạm thời thiết bị Cl Plus [6].

5.11.1. Các khả năng của CICAM PIN

Tài nguyên kiểm soát nội dung mã PIN cung cấp các tính năng cho phép CICAM quản lý PIN với nhiều mức. CICAM thông báo các khả năng của nó để trả lời yêu cầu từ máy chủ về các khả năng. CICAM có thể đề nghị không quản lý mã PIN đối với tất cả hoặc có thể thông báo khả năng xử lý việc quản lý mã PIN đối với nội dung được CA kiểm soát, khả năng xử lý việc quản lý mã PIN đối với cả nội dung FTA và được CA kiểm soát.

Các APDU của các khả năng cc_PIN, xem điều 11.3.2.1, cho phép máy chủ xác định cách các sự kiện và các dịch vụ chương trình được kiểm soát của cha mẹ đối với mã PIN bất kỳ quản lý. Tài nguyên này được tất cả các thiết bị máy chủ phân tích và thực hiện.

Các khả năng của mã PIN được gửi đến máy chủ sử dụng cc_PIN_capabilities_reply () APDU. APDU này được gửi để trả lời một cc_PIN_capabilities_req () từ máy chủ. cc_PIN_capabilities_reply () APDU cũng được gửi đến máy chủ bất cứ khi nào các khả năng của mã PIN thay đổi kể cả khi đánh giá độ tuổi hiệu quả mà CAM bắt đầu quản lý mã PIN bị thay đổi trong CICAM này.

APDU của các khả năng của mã PIN chứa thông tin cho phép CICAM thông báo cho máy chủ cách mã PIN bất kỳ đang được xử lý để đảm bảo rằng máy chủ không can thiệp vào hoạt động này. APDU này chứa thời gian và ngày thay đổi cuối cùng của mã PIN cho phép máy chủ xác định nếu có ghi lại được lập lịch yêu cầu một mã PIN mới.

Khả năng của CICAM PIN được trình bày trong các phần sau.

5.11.1.1. Không có khả năng của CICAM PIN

CICAM không thực hiện bất kỳ đánh giá của cha mẹ đối với bất kỳ dịch vụ (FTA và CAS). Máy chủ có thể tùy chọn cung cấp một cơ chế để thay thế cha mẹ để đánh giá theo quyết định của bất kỳ thiết lập đánh giá của cha mẹ của người sử dụng. Máy chủ cung cấp một giao diện người sử dụng bản địa để nhập PIN.

5.11.1.2. Khả năng của CICAM PIN chỉ dành cho các dịch vụ CA

CICAM không thực hiện bất kỳ quản lý đánh giá đối với các dịch vụ FTA. CICAM thực hiện quản lý mã PIN CAS và phải sử dụng một bản tin MMI cao cấp hoặc ứng dụng để có được mã PIN từ người sử dụng. Máy chủ có thể tùy chọn làm cha mẹ để đánh giá đối với các dịch vụ FTA theo quyết định của người sử dụng để thiết lập một đánh giá của cha mẹ và các dịch vụ CA nếu các thiết lập đánh giá của cha mẹ trong máy chủ là thấp hơn so với đánh giá được cung cấp trong các khả năng của CICAM PIN, trong trường hợp này, máy chủ cung cấp một giao diện người sử dụng bản địa để nhập PIN.

5.11.1.3. Các khả năng của CICAM PIN dành cho các dịch vụ CA và FTA

Máy chủ có thể yêu cầu CICAM hiển thị một màn hình MMI dành cho các dịch vụ FTA và các dịch vụ CA có thiết lập đánh giá của cha mẹ trong máy chủ thấp hơn so với đánh giá được cung cấp trong các khả năng của CICAM. Máy chủ không cần cung cấp một giao diện người sử dụng bản địa để nhập PIN và có thể sử dụng CICAM để thực hiện nhập PIN. CICAM phải được kiểm soát hiển thị PIN MMI, PIN MMI chỉ hiển thị khi có yêu cầu một cách rõ ràng của máy chủ đối với các dịch vụ FTA. CICAM xác nhận mã PIN được nhập là đúng với mã CICAM PIN hoặc mã PIN của máy chủ được gửi trong cc_PIN_MMI_req () trước khi trở về trạng thái trong cc_PIN_reply (). CICAM thực hiện việc quản lý CAS PIN và phải sử dụng một bản tin MMI cao cấp hoặc ứng dụng để có được mã PIN từ người sử dụng.

5.11.1.4. Các khả năng của CICAM PIN chỉ dành cho các dịch vụ CA (mã PIN được lưu trữ)

CICAM không thực hiện bất kỳ quản lý đánh giá đối với các dịch vụ FTA. CICAM thực hiện quản lý mã CAS PIN và phải sử dụng MMI cấp cao hoặc ứng dụng để có được mã PIN từ người sử dụng. Máy chủ có thể tùy chọn thực hiện đánh giá của cha mẹ, theo quyết định của người sử dụng thiết lập một đánh giá của cha mẹ dành cho cả các dịch vụ FTA và các dịch vụ CA khi thiết lập đánh giá của cha mẹ trong máy chủ là thấp hơn so với đánh giá được cung cấp trong các khả năng của CICAM PIN, trong trường hợp này máy chủ cung cấp một màn hình hiển thị bản địa để nhập PIN.

CICAM có thể cung cấp một khả năng yêu cầu mã PIN dành cho ghi lại và máy chủ phải lưu trữ nó trong trường hợp nó được yêu cầu trong quá trình ghi lại. Yêu cầu mã PIN này không được ngăn chặn nội dung không yêu cầu PIN đang được xem, tức là, đối với nội dung không yêu cầu PIN thì một yêu cầu mã PIN có thể nhanh chóng được hiển thị sau thời gian chờ hoặc bị người sử dụng hủy bỏ.

Máy chủ có thể sử dụng bản tin bắt đầu ghi lại để cung cấp cho CICAM mã CICAM PIN. Trong trường hợp này CICAM không được yêu cầu người sử dụng nhập mã PIN để cho phép việc ghi lại không bị gián đoạn.

5.11.1.5. Các khả năng của CICAM PIN dành cho các dịch vụ CA và FTA (mã PIN được lưu giữ)

Máy chủ có thể yêu cầu CICAM hiển thị một màn hình MMI dành cho các dịch vụ FTA và các dịch vụ CA có thiết lập đánh giá của cha mẹ trong máy chủ thấp hơn so với đánh giá được cung cấp trong các khả năng của CICAM. Máy chủ không cần cung cấp một giao diện bản địa để nhập PIN mà sử dụng CICAM MMI. CICAM không được hiển thị PIN MMI một cách bừa bãi trừ khi có yêu cầu một cách rõ ràng của máy chủ đối với các dịch vụ FTA. CICAM xác nhận mã PIN được nhập là chính xác sau khi so sánh với CICAM PIN và/hoặc mã PIN của máy chủ được gửi trong cc_PIN_MMI_req () trước khi trở về trạng thái trong cc_PIN_reply (). CICAM thực hiện việc quản lý CAS PIN và phải sử dụng bản tin MMI cấp cao hoặc ứng dụng để có được mã PIN từ người sử dụng.

Máy chủ có thể sử dụng bản tin bắt đầu ghi lại để cung cấp cho CICAM mã CICAM PIN. Trong trường hợp này, CICAM không được yêu cầu người sử dụng nhập mã PIN để cho phép việc ghi lại không bị gián đoạn.

Khi chuyển đến chế độ tạm dừng hay chế độ xem và lưu đệm, nếu mã PIN được cache đã được nhập không chính xác (thông qua khởi tạo ghi) thì mã PIN đang xem phải được thay thế bằng PIN đã cache.

5.11.2. Mã CICAM PIN

CICAM có thể cung cấp việc quản lý mã PIN và mức đánh giá độ tuổi để cung cấp việc truy nhập được cha mẹ kiểm soát đối với nội dung. CAS có thể có được yêu cầu đối với một mã PIN trực tiếp từ hệ thống CAS (ví dụ ECM) hoặc bằng các sử dụng thông tin SI trong dòng truyền tải như nhãn DVB parental_rating_descriptor.

Hình 5.22: Biểu đồ trình tự ghi lại tự động

Trong một chế độ ghi lại tự động, việc nhập mã PIN có thể được yêu cầu và cc_PIN_cmd () được sử dụng để truyền mã PIN cho CICAM tại thời điểm người sử dụng đăng ký một sự kiện ghi lại để xác nhận mã PIN là đúng. cc_PIN_cmd () được sử dụng dành cho ghi lại tự động hoặc tạm dừng. CICAM phải xác nhận mã PIN bằng cách sử dụng một cc_PIN_reply (). Mã PIN được gửi trong cc_PIN_cmd () phải không được lưu trữ hoặc sử dụng cho việc ghi không giám sát hoặc chế độ tạm dừng bởi CICAM, thay vào đó CICAM chỉ được sử dụng PIN đã được cung cấp trong Giao thức khởi tạo ghi.

Để bắt đầu ghi lại, một mã PIN có thể được yêu cầu để khởi tạo CICAM giải xáo trộn, trong trường hợp này bản tin SAC bắt đầu ghi lại có thể được sử dụng để truyền mã PIN cho CICAM mà không có tương tác với người sử dụng. CICAM phải cung cấp mã PIN cho CAS nếu PIN được yêu cầu để giải xáo trộn chương trình được ghi lại và xác nhận mã PIN bằng cách sử dụng cc_PIN_event () có chứa đánh giá độ tuổi trưởng thành đối với các người sử dụng trong quá trình phát lại. Nếu đánh giá của cha mẹ dành cho chương trình thay đổi thì không được yêu cầu máy chủ gửi lại PIN và CICAM cung cấp mã PIN này cho CAS và gửi một cc_PIN_event () được cập nhật đến máy chủ.

Để dừng việc ghi lại trong chế độ ghi lại tự động, máy chủ gửi một bản tin dừng ghi lại, CICAM dừng việc giải xáo trộn nội dung nếu mã PIN này được yêu cầu và yêu cầu mã PIN từ người sử dụng trước khi bắt đầu việc giải xáo trộn lại nội dung này.

Trong khi phát lại, Hình 5.22 chỉ ra rằng CICAM nhận được một cc_PIN_playback () APDU khi máy chủ nhận được một "pin_event" trong quá trình ghi lại. Tùy thuộc vào các yêu cầu của nhà điều hành hoặc pháp luật địa phương, CICAM xác định xem việc kiểm soát của cha mẹ nên được thực thi. Trong trường hợp đó mà CICAM quyết định việc kiểm soát của cha mẹ không phải được thực thi thì CICAM trực tiếp gửi cc_PIN_reply APDU (mã PIN chính xác). Máy chủ làm trống đối với AV trong giai đoạn giữa nhận được "pin_event" trong quá trình ghi lại và nhận được cc_PlN_reply () APDU từ CICAM, điều này có thể gây ra nhấp nháy. Có thể tránh hiện tượng nhấp nháy bằng cách lập lịch đối với cc_PIN_playback () APDU sớm một hoặc nhiều giây để cho phép CICAM đủ thời gian gửi cc_PIN_reply () APDU trước khi gặp phải "pin_event" thực trong quá trình ghi lại. Nếu gặp phải "pin_event" trong quá trình ghi lại trước khi máy chủ nhận được cc_PIN_reply () APDU thì máy chủ phải làm trống đối với AV cho đến khi cc_PIN_reply () APDU được nhận với mã PIN chính xác.

Hình 5.23: Biểu đồ trình tự chế độ tạm dừng

Khi phát lại, máy chủ phải gửi cc_PIN_playback () APDU với đánh giá độ tuổi được CICAM cung cấp trên cc_PIN_event () khi việc ghi lại đã được thực hiện đối với CICAM đã gửi cc_PIN_event () này. CAS kiểm tra việc đánh giá và yêu cầu một MMI cấp cao hoặc áp dụng để có được thông tin của PIN này, nếu được yêu cầu, trước khi trả lại một cc_PIN_reply () đến máy chủ. CICAM trả lời máy chủ bằng một cc_PIN_reply () để xác nhận xem máy chủ có thể tiếp tục phát lại nội dung được ghi lại.

Hình 5.23 chỉ ra rằng trong qua trình xem nội dung truyền hình trực tiếp, máy chủ nhận được một cc_PIN_event () APDU sau đó nó làm trống đối với AV. Việc máy chủ chủ động làm trống đối với AV khi trường trạng thái PINcode trong cc_PIN_event () APDU là "0x04" (việc làm trống Video là không bắt buộc) là không cần thiết đối với máy chủ. “PIN_event” vẫn phải được lưu trữ với nội dung được liên kết để có thể thực thi việc kiểm soát của cha mẹ trong quá trình phát lại.

Nếu máy chủ dừng ghi, nó sẽ gửi một bản tin dừng ghi. CICAM phải ngừng sử dụng mã PIN đã được lưu trữ để giải xáo trộn nội dung. Nếu PIN người xem đã nhập trước đó là chính xác thì nó sẽ được sử dụng để người xem có thể xem các nội dung mà không bị gián đoạn. Nếu PIN mà người xem đã nhập trước đó là không chính xác thì CICAM phải thi hành chế độ kiểm soát của cha mẹ thích hợp.

5.11.3. Mã PIN của máy chủ

Mã PIN của máy chủ là mã PIN riêng thường được chỉ có máy chủ và người sử dụng thiết bị đầu cuối quản lý. Tài nguyên kiểm soát nội dung cho phép mã CICAM PIN được máy chủ sử dụng để trình bày nội dung FTA được đánh giá độ tuổi.

Trên một dịch vụ FTA, máy chủ xác định xem đánh giá độ tuổi trưởng thành của dịch vụ này có cao hơn so với đánh giá được người sử dụng thiết lập thì máy chủ gửi cc_PIN_MMI_req () với mã PIN của máy chủ đến CICAM để sử dụng một bản tin MMI cao cấp hay ứng dụng để có được mã PIN từ người sử dụng. CICAM xác nhận mã PIN được nhập này giống mã CICAM PIN hoặc mã PIN được gửi trong cc_PIN_MMI_req () trước khi trả lại cc_PIN_reply (). Hình 5.24 được cung cấp để tham khảo:

Hình 5.24 - PIN dành cho FTA

5.11.4. Thông báo khi mã PIN được yêu cầu

cc_PIN_event () APDU được CICAM gửi để thông báo cho máy chủ rằng một mã PIN được yêu cầu để giải xáo trộn chương trình được ghi lại và cung cấp đánh giá của cha mẹ để sử dụng trong quá trình phát lại và ngày mà nó đã thay đổi. Nếu đánh giá của cha mẹ đối với chương trình thay đổi thì không bắt buộc máy chủ phải gửi lại PIN mà CICAM cung cấp mã PIN này cho CAS và gửi một cc_PIN_event() được cập nhật.

5.11.5. Chuyển đánh giá của cha mẹ sang CICAM

cc_PIN_playback APDU, xem điều 11.3.2.5, được gửi đến CICAM khi gặp phải một cc_PIN_event () khi bắt đầu phát lại và khi đánh giá của cha mẹ đối với nội dung thay đổi, ví dụ như vượt qua các ranh giới của sự kiện. APDU này được sử dụng để truyền đánh giá của cha mẹ hiện tại đến CICAM để nó có thể quản lý các mã PIN.

Khi cố gắng phát lại và CICAM là không có hoặc không trả lời thì máy chủ phải tiếp tục vô hiệu đầu ra đối với nội dung được cha mẹ kiểm soát cho đến lúc mà CICAM lại có mặt trong máy chủ và có thể xử lý yêu cầu phát lại mã PIN.

5.11.6  Lưu trữ mã PIN

Máy chủ có thể cung cấp khả năng lưu trữ một mã PIN để sử dụng như một bộ phận của bản tin khởi tạo ghi, vì vậy CICAM vẫn có thể tiếp tục giải xáo trộn nội dung khi gặp phải sự kiểm soát đánh giá của cha mẹ. Máy chủ sẽ chỉ sử dụng mã PIN đã lưu này cho quá trình ghi hoặc để xác nhận mã PIN cho một sự kiện trong tương lai.

Máy chủ không được tiết lộ mã PIN đã được lưu trữ cho người dùng dưới mọi hình thức, ví dụ thông qua giao diện người dùng gốc hoặc qua menu.

5.12. Ghi và phát lại

Phần này trình bày các yêu cầu về lưu trữ ghi lại và phát lại sau đó của một máy chủ ghi lại nội dung được Cl Plus bảo vệ bằng cách sử dụng tài nguyên kiểm soát nội dung. Luôn luôn yêu cầu máy chủ giữ nguyên các thông số thiết lập của URI, các thông báo kiểm soát của cha mẹ (PIN) và giấy phép nội dung.

Những thay đổi của URI, giấy phép và mã PIN phải được lưu trữ một cách chính xác với nội dung chương trình sao cho mỗi chuyển đổi có thể được máy chủ thực hiện lại một cách chính xác khi phát lại sau đó phù hợp các sự kiện với vị trí nội dung gốc được cung cấp. Thông báo mã PIN chứa một mốc dấu thời gian và có thể được sắp xếp một cách chính xác với dòng truyền tải. URI và giấy phép không chứa mốc dấu thời gian và phải được sắp xếp với nội dung này dựa trên thời gian nhận được chúng tại máy chủ.

Máy chủ không tổng hợp các giấy phép hoặc các mã PIN. Việc bảo vệ quyền kiểm soát nội dung của các giấy phép, các URI và các mã PIN phải được áp dụng từ vị trí trong dòng truyền tải đã được việc bảo vệ này áp dụng trong quá trình ghi lại đến vị trí được bảo vệ tiếp theo trong quá trình ghi lại hoặc phần cuối của dòng truyền tải. Phạm vi của mỗi thành phần bảo vệ nội dung được quy định như sau:

• URI mở rộng từ vị trí được thông báo đến vị trí được URI thông báo tiếp theo, hoặc phần cuối của ghi lại, theo hướng tiến.

• Giấy phép mở rộng từ vị trí được thông báo đến vị trí được giấy phép hoặc URI tiếp theo thông báo, hoặc phần cuối của ghi lại, theo hướng tiến.

• PIN mở rộng từ vị trí được thông báo đến vị trí được mã PIN tiếp theo thông báo, hoặc phần cuối của ghi lại, theo hướng tiến.

• Bất kỳ chuyển đổi được trình bày ở trên có thể xảy ra bất cứ lúc nào trong quá trình ghi lại như trong hình 5.25 đã mô tả quá trình ghi lại theo thời gian mà không phải là theo sự kiện.

• Trong hình 5.25, nội dung được bảo vệ như sau, trong đó URI # n là một thay đổi trong URI, License # n là giấy phép nội dung và mã PIN # n là một sự kiện kiểm soát của cha mẹ nơi đánh giá của cha mẹ đã thay đổi và không hiển thị các mã PIN khác nhau. Theo mục đích của ví dụ này thì chúng ta giả thiết rằng việc ghi lại này bao gồm ba sự kiện, chúng ta thường sẽ kiểm tra mỗi sự kiện riêng được ghi lại.

• Sự kiện # 1: là nội dung được giấy phép bảo vệ bằng giấy phép # 1 và URI # 1 có điều khiển của cha mẹ PIN # 1 với thời gian chờ một phút để chuyển sang ghi lại.

• Sự kiện # 2: là nội dung không được giấy phép bảo vệ và có URI # 2, có kiểm soát của cha mẹ PIN # 2 đang có hiệu lực.

• Sự kiện # 3: là nội dung được giấy phép bảo vệ bằng giấy phép # 2 và URI # 3 và có kiểm soát của cha mẹ PIN # 2 đang có hiệu lực.

• Nên lưu ý rằng giấy phép # 1 và giấy phép # 2 có thể là cùng một giấy phép hoặc là khác nhau. Trong khi ở chế độ ghi lại, URI và giấy phép được ghép cùng nhau trong một bản tin đơn. Máy chủ không phân tích giấy phép này mà chỉ đơn giản là trả về nó trong hoạt động phát lại tại một thời điểm thích hợp trong dòng truyền tải khi một giấy phép mới được nhập vào.

Hình 5.25 - Ví dụ về trình tự ghi lại

5.12.1. Phiên phát lại

Khi phát lại nội dung được ghi lại, máy chủ phải bao gồm một phiên. Khi xem một nội dung được ghi lại thì phiên này phải được mở, phiên này không được đóng cho đến khi việc phát lại dừng, việc tạm dừng không làm đóng phiên. Một phiên có thể được đóng tự động khi giới hạn thời gian lưu giữ nội dung chấm dứt, lúc này nội dung được giới hạn thời gian lưu giữ bảo vệ bị loại bỏ.

Các giấy phép được sử dụng, thường được gặp phải, trong quá trình phát lại. Việc sử dụng của một giấy phép yêu cầu một trao đổi giấy phép với CICAM và giấy phép và URI liên kết với ghi lại được trao đổi với một giấy phép và URI mới được liên kết với ghi bằng cách thay thế mỗi giá trị được lưu trữ hiện tại. Giấy phép chỉ được sử dụng trong trường hợp phát lại, không phụ thuộc vào việc di chuyển hướng của người sử dụng giữa các giấy phép khác nhau đã được sử dụng trong phiên hiện tại.

Chuyển đổi đánh giá của cha mẹ (PIN) trong quá trình ghi lại yêu cầu máy chủ loại bỏ tất cả các thành phần có thể hiển thị của nội dung được ghi lại (video thì trống, âm thanh thì câm, vô hiệu hóa phụ đề, v.v..) cho đến khi thu được một mã PIN hợp lệ từ CICAM, thông qua người sử dụng, khi nội dung này có thể được khôi phục. Phải thực hiện trao đổi PIN với CICAM khi gặp phải bất kỳ sự kiện PIN trong ghi lại ở cả hai hướng tiến hoặc lùi khi nội dung này được hiển thị. CICAM (nhà điều hành dịch vụ) có thể làm giảm sự tương tác của người sử dụng trong trường hợp phát lại khi mã PIN hợp lệ đã được nhập và mọi yêu cầu mã PIN từ máy chủ không cần sự tương tác của người sử dụng miễn là đánh giá của cha mẹ bằng việc nhập mã PIN đầu tiên là đủ, hoạt động chính xác của CICAM được nhà điều hành dịch vụ và các quy định quốc gia quy định.

Di chuyển theo hướng tiến và lùi trong quá trình ghi lại yêu cầu máy chủ giữ nguyên tất cả thông số giới hạn của giấy phép, URI và PIN tại mỗi điểm chuyển đổi trong quá trình ghi lại. Khi di chuyển theo lùi thì yêu cầu máy chủ sử dụng lại các thông số giới hạn khi gặp phải một sự kiện giới hạn trong quá trình ghi lại, điều này yêu cầu máy chủ để tìm ra loại chuyển đổi trước đó và áp dụng phù hợp thông số giới hạn này.

URI được trả về từ một trao đổi giấy phép của CICAM có thể làm thay đổi giấy phép và URI được ghi lại hiện tại và phải được liên kết với nội dung này ở cùng một vị trí như ban đầu, làm thay thế giấy phép và URI hiện tại. URI mới phải được sử dụng ngay lập tức đối với việc phát lại. URI mới có thể làm thay đổi giới hạn thời gian lưu giữ đã được áp dụng một cách tương tự trong quá trình ghi lại, xem xét độ dài của nội dung này khi xem với một thời gian phát lại bình thường. Ví dụ như xem xét một chương trình 2 giờ (120 phút) có thay đổi giới hạn lưu giữ từ 30 ngày sang 90 phút. Ở ngay thời điểm mà URI được thay đổi thì các byte đầu tiên của nội dung được ghi lại này tại chuyển đổi URI có giới hạn thời gian lưu trữ mới là 90 phút, byte cuối cùng của sự kiện được ghi lại 120 phút có giới hạn thời gian lưu trữ là 120 + 90 hoặc 210 phút. Một URI tồn tại mà không có một giấy phép không được trình bày lại cho CICAM khi phát lại và không được thay thế trong quá trình ghi lại.

Trường hợp ghi lại có nhiều URI với các giá trị giới hạn lưu giữ khác nhau thì yêu cầu máy chủ quản lý các giới hạn lưu giữ của từng vùng URI theo Thỏa thuận giấy phép Cl Plus [6]. Máy chủ có thể xử lý mỗi giới hạn lưu giữ của vùng URI hoặc áp dụng giới hạn lưu trữ hạn chế nhất đối với toàn bộ nội dung. Trong mỗi trường hợp, máy chủ không được vượt quá giới hạn lưu giữ đã thông báo đối với bất kỳ vùng URI. Phương pháp chính xác mà máy chủ quản lý các thời gian lưu khác nhau trong một nội dung ghi lại là cụ thể nhưng trong mọi trường hợp phải được quản lý theo Thỏa thuận giấy phép Cl Plus [6].

Máy chủ không được loại bỏ nội dung ghi lại được lưu trữ khi nó vượt quá số lượt phát của nó. Nếu nhà điều hành dịch vụ yêu cầu nội dung này phải bị loại bỏ khi nó đã được xem khi phát lại, khi chuyển đổi số lượt phát từ một sang không (0) xảy ra thì giới hạn lưu trữ này phải được thiết lập một cách thích hợp thông qua URI phát lại để bắt buộc máy chủ loại bỏ nội dung này khi giới hạn thời gian lưu giữ đã bị vượt quá.

5.13. Cung cấp SRM

CICAM có thể nhận các tập tin dữ liệu SRM, theo quy định tại [34]. Các tập tin dữ liệu SRM thực hiện chức năng danh sách đen đối với HDCP [34]. Các tập tin dữ liệu SRM này được áp dụng cho chức năng HDCP của máy chủ, tùy thuộc vào máy chủ triển khai một đầu ra HDCP trong chế độ nguồn hoặc lặp lại.

Việc thực hiện chức năng HDCP trong máy chủ Cl Plus phải phù hợp với Đặc tả về giấy phép Cl Plus [33]. Máy chủ Cl Plus yêu cầu các tập tin SRM phải chấp nhận những tập tin này nếu CICAM khởi tạo việc truyền các tập tin SRM đó.

5.13.1. Giao thức truyền tập tin dữ liệu

Phần này mô tả một giao thức bắt buộc để truyền các tập tin dữ liệu SRM từ CICAM đến máy chủ. Trách nhiệm của Cl Plus là truyền các tập tin dữ liệu SRM một cách an toàn. Việc áp dụng chính xác các tập tin SRM là một phần của chức năng HDCP và nằm ngoài phạm vi của tiêu chuẩn này.

5.13.1.1. Tổng quan bản tin và khởi tạo

Quá trình này được trình bày trong hình 5.26:

Hình 5.26 - Cung cấp các tập tin dữ liệu SRM

Bảng 5.21 - Hành vi giao thức truyền tập tin dữ liệu SRM

5.13.2. Các điều kiện truyền dữ liệu

CICAM sẽ bắt đầu khởi tạo việc truyền tập tin dữ liệu lần đầu tiên khi nó phát hiện một tập tin dữ liệu SRM. Trong trường hợp máy chủ không yêu cầu tập tin này, nó có thể thông báo điều này trong bản tin xác nhận và CICAM phải tránh gửi các tập tin dữ liệu SRM sau đó. Trong mọi trường hợp máy chủ phải trả lời bằng một xác nhận để xóa bản tin. Khi máy chủ thông báo rằng nó đã nhận được tập tin dữ liệu SRM này thì CICAM phải tránh gửi các tập tin giống nhau nhiều lần.

Hình 5.27 trình bày hoạt động truyền tập tin dữ liệu của CICAM.

CHÚ THÍCH: thời gian chờ được quy định là 10 giây.

Hình 5.27 - Tổng quan các điều kiện cung cấp tập tin dữ liệu phía CICAM

6. Cơ chế xác thực

6.1. Đăng ký và liên kết CICAM

Việc đăng ký và liên kết CICAM được thực hiện theo ba bước:

• Kiểm tra giấy chứng nhận & trao đổi mã khóa DH.

• Kiểm tra mã khóa xác thực.

• Tùy chọn thông báo trả về nhà điều hành dịch vụ (chỉ đối với chế độ đăng ký dịch vụ).

Các bước này được mô tả trong các phần sau.

6.1.1. Kiểm tra giấy chứng nhận & trao đổi mã khóa DH

Máy chủ và CICAM bắt đầu giao thức xác thực bằng cách trao đổi chuỗi chứng nhận của máy chủ, chuỗi chứng nhận của CICAM, dữ liệu được đóng dấu và mã khóa công khai Diffie-Hellman. Trước khi việc xác thực hoàn thành, CICAM chỉ có quyền đối với các chương trình có dữ liệu EMI được thiết lập giá trị là 00 (cho phép sao chép).

CICAM kiểm tra các đóng dấu được chứa trong chuỗi chứng nhận của máy chủ và đóng dấu trên mã khóa công khai Diffie- Hellman. Đây là một giao thức xác thực lẫn nhau và máy chủ phải kiểm tra đóng dấu được chứa trong chuỗi chứng nhận của CICAM cùng với đóng dấu trên mã khóa công khai Diffie- Hellman. DHPH được máy chủ bảo vệ bằng một đóng dấu có liên quan đến HDQ của máy chủ. Phía CICAM kiểm tra DHPH đã nhận với HDP của máy chủ mà nó có được từ giấy chứng nhận thiết bị máy chủ. DHPM được bảo vệ theo một cách tương tự bằng cách sử dụng MDQ để đóng dấu và MDP để kiểm tra.

Nếu chuỗi chứng nhận của máy chủ kiểm tra cùng với đóng dấu trên mã khóa công khai Diffie-Hellman, HOST_ID thu được từ giấy chứng nhận thiết bị máy chủ. Tương tự, nếu chuỗi chứng nhận của CICAM kiểm tra cùng với đóng dấu trên mã khóa công khai Diffie-Hellman, CICAM_ID thu được từ giấy chứng nhận thiết bị CICAM.

Nếu việc kiểm tra giấy chứng nhận hoặc đóng dấu không thành công thì CICAM không được loại bỏ mạng CA (tức là không được giải mã mạng CA từ TS đến) ngay cả khi thuê bao được quyền để nhận dịch vụ này. CICAM hiển thị một bản tin lỗi bằng cách sử dụng tài nguyên MMI trên máy chủ, xem điều 5.4.3 để biết chi tiết về các bản tin lỗi và EN 50221 [7], điều 8.6 về giải thích tài nguyên MMI. Nếu máy chủ tạm thời không thể trả lời yêu cầu từ một tương tác MMI thì CICAM thử lại cho đến khi máy chủ rỗi.

6.1.2. Kiểm tra mã khóa xác thực

CICAM và máy chủ lấy được mã khóa xác thực dài hạn từ việc trao đổi dữ liệu giữa CICAM và máy chủ trong giai đoạn đầu tiên của quá trình xác thực. Mã khóa xác thực được tính từ mã khóa riêng DH cùng với dữ liệu duy nhất từ liên kết cụ thể này, HOST_ID và CICAM_ID (xem điều 6.2.3.4 để biết chi tiết).

CICAM gửi một bản tin yêu cầu đến máy chủ để yêu cầu mã khóa xác thực được lấy từ máy chủ. Máy chủ trả lời bằng một bản tin xác nhận chứa mã khóa xác thực được yêu cầu. Sau khi nhận, CICAM so sánh mã khóa xác thực nhận được với một mã khóa mà nó đã lưu trữ trước đó. Nếu so sánh của CICAM thành công, máy chủ đã chứng minh được rằng nó có mã khóa xác thực tương tự và CICAM chấp nhận rằng máy chủ là hợp pháp để cho phép truyền. Cả hai bên đều lưu trữ mã khóa xác thực này trong bộ nhớ ổn định để nó có sẵn để tính toán mã khóa dành cho SAC và CC. Tham khảo điều 7 (SAC) và điều 8 (Mã khóa kiểm soát nội dung) để biết chi tiết.

Nếu một mã khóa xác thực phù hợp không nhận được trong vòng 5 giây tính từ bản tin yêu cầu thì CICAM không được loại bỏ mạng CA (tức là không được giải mã TS đến), ngay cả khi thuê bao được quyền để nhận dịch vụ này.

6.1.3. Báo cáo trả về nhà điều hành dịch vụ

Khi hệ thống được triển khai trong chế độ đăng ký dịch vụ, CICAM khởi tạo một bản tin MMI "đăng ký", cho phép dữ liệu được thông báo lại cho nhà cung cấp dịch vụ. Tham khảo điều 5.4.2 để biết chi tiết.

Khi ở chế độ đăng ký dịch vụ, CICAM yêu cầu thiết bị đầu cuối xác nhận CICAM_ID và HOST_ID. Quá trình xác nhận CC của CICAM yêu cầu hệ thống CA kiểm tra xem HOST_ID hoặc CICAM_ID có được liệt kê trong các SOCRL. Cơ chế chính xác này được mô tả trong điều 5.5.

6.1.4. Hoạt động hệ thống CC

Hình 6.1 trình bày cách xác thực 3 bước được tích hợp thành hoạt động CC chung. Nội dung này có tính tham khảo và những cách khác là có thể. Quá trình xác thực 3 bước này là bắt buộc.

Hệ thống kiểm soát nội dung của CICAM (CC) được trình bày trong hình 6.1 bao gồm các bước cơ bản sau đây:

1) Tài nguyên CC phải được máy chủ cung cấp và các mô-đun cung cấp một tài nguyên CC phải bị quản lý tài nguyên của máy chủ bỏ qua. Máy chủ phải hỗ trợ một phiên dành cho tài nguyên CC đối với mỗi khe Cl. Trong quá trình kiểm tra hồ sơ (xem Hình 6.1 và Hình 6.2), máy chủ phải thông báo rằng một tài nguyên kiểm soát nội dung có sẵn. Nếu tài nguyên không được thông báo thì điều này gây ra lỗi của hệ thống kiểm soát nội dung và hệ thống phải tiếp tục với bước (13).

2) Một phiên dành cho tài nguyên kiểm soát nội dung được CICAM mở, điều 11.3. Nếu một phiên hợp lệ không được mở thành công thì hệ thống kiểm soát nội dung phải được xem là thất bại. CICAM phải gửi APDU cc_open_req đến máy chủ. Máy chủ phải trả lời bằng một cc_open_cnf APDU trong vòng 5 giây (xem điều 6.2.1).

Nếu không trả lời yêu cầu này trong vòng 5 giây thì gây ra một lỗi và hệ thống phải tiếp tục ở bước (25).

cc_system_id_bitmaskin trong trả lời của phải bao gồm CC phiên bản 1, xem điều 11.3.1.2. Nếu cc_system_id_bitmaskdoes không được bao gồm CC phiên bản 1 hệ thống phải tiếp tục với bước (24).

3) CICAM kiểm tra xem có một mã khoá xác thực được lưu trữ trong bộ nhớ ổn định. Nếu CICAM chứa một mã khóa xác thực hợp lệ (AKM) thì nó phải yêu cầu máy chủ để gửi mã khóa xác thực của nó (AKH). Nếu CICAM không có AKM hợp lệ thì CICAM và máy chủ phải tiếp tục với bước (6).

4) CICAM yêu cầu máy chủ gửi mã khóa xác thực của nó (AKH). Máy chủ phải trả lời bằng AKH của nó trong vòng 5 giây. Nếu AKH không có sẵn thì nó phải gửi một giá trị với tất cả các số là không. Giá trị với tất cả các số là không được CICAM công nhận là một AKH không hợp lệ.

5) CICAM phải so sánh AKM được lưu trữ của nó với AKH nhận được. Nếu mã khóa xác thực này phù hợp thì việc xác thực trước đó đã được hoàn thành thành công và các giấy chứng nhận được xem là hợp lệ. Mã khóa mật DH (DHSK) và các mã khóa xác thực (AKM/AKH) được tính trên cả hai phía sau đó được lưu giữ, mã khóa dành cho SAC (SAK và SEK) và mã khóa kiểm soát nội dung (CCK) được tạo (tạo lại) một cách độc lập và được đồng bộ cả hai phía. Sau đó hệ thống phải tiếp tục với bước (15). Nếu các mã khóa xác thực không phù hợp thì hệ thống được yêu cầu xác thực và phải tiếp tục với bước (8). Lưu ý rằng máy chủ có nhiều mô-đun và nhiều khe được quy định tại điều 6.3.

6) CICAM kích hoạt khởi tạo giao thức DH và trao đổi giấy chứng nhận, giao thức xác thực dựa trên DH chính xác được mô tả trong hình 6.2 bước (1).

Hình 6.1 - Tổng quan CICAM và máy chủ trong hoạt động CC

7) Nếu giao thức DH được hoàn thành thành công, hệ thống này phải tiếp tục với bước (8). Bất cứ lỗi trong việc hoàn thành của giao thức DH gây ra lỗi của hệ thống kiểm soát nội dung và hệ thống phải tiếp tục với bước (11).

8) CICAM phải yêu cầu máy chủ xác nhận mã khóa xác thực của nó (AKH) trong vòng 5 giây.

9) CICAM phải so sánh mã khóa xác thực AKM của nó với AKH nhận được. Nếu chúng không bằng nhau, điều này gây ra một lỗi của hệ thống kiểm soát nội dung (xem điều 6.1.1) và hệ thống phải tiếp tục với bước (20). Nếu chúng bằng nhau thì CICAM và máy chủ kết thúc hoạt động Diffie- Hellman hoàn thành thành công và phải lưu trữ các mã khóa xác thực này (DHSK và AKM/AKH) vào bộ nhớ ổn định.

10) Hệ thống này hoạt động hoàn toàn để xử lý nội dung được mã hóa CA và rõ ràng miễn là người sử dụng có các quyền cần thiết và sau khi tính toán thành công SAC (xem điều 7) và các mã khóa CC (xem điều 8), máy chủ sẽ có thể hiển thị nội dung.

11) CICAM phải thiết lập trạng thái xác nhận là không thành công.

12) Hệ thống này bị giới hạn chỉ xử lý nội dung rõ ràng.

6.2. Giao thức xác thực

Điều 6.2.1 trình bày các bản tin của giao thức xác thực được trao đổi qua các giao diện bên ngoài. Điều 6.2.2 trình bày các điều kiện xác thực. Điều 6.2.3 trình bày các tính toán mã khóa và kiểm tra địa phương của giao thức xác thực.

CICAM không nên cố xác thực cho đến thời điểm mà cả CICAM và máy chủ đảm bảo rằng các giấy chứng nhận có thể được xác nhận. Ví dụ điều này có thể được thực hiện bằng cách sử dụng tài nguyên ngày và thời gian, xem EN 50221 [7], điều 8.5.2.

6.2.1. Tổng quan bản tin và khởi tạo

Xác thực được thực hiện theo ba bước:

CHÚ THÍCH: Lưu đồ này không thể hiện rằng mọi hành vi (không) được đồng bộ/ khối hóa. Lưu đồ này cũng cho rằng CICAM không lưu giữ một AKM hợp lệ.

Hình 6.2 - Biểu đồ trình tự trao đổi xác thực

Quá trình này được xác định trong Bảng 6.1:

Bảng 6.1 - Trao đổi xác thực