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)

  • Thuộc tính
  • Nội dung
  • Tiêu chuẩn liên quan
  • Lược đồ
  • Tải về
Mục lục Đặt mua toàn văn TCVN
Lưu
Theo dõi văn bản

Đây là tiện ích dành cho thành viên đăng ký phần mềm.

Quý khách vui lòng Đăng nhập tài khoản LuatVietnam và đăng ký sử dụng Phần mềm tra cứu văn bản.

Báo lỗi
  • Báo lỗi
  • Gửi liên kết tới Email
  • Chia sẻ:
  • Chế độ xem: Sáng | Tối
  • Thay đổi cỡ chữ:
    17
Ghi chú

Tiêu chuẩn Việt Nam TCVN 11819:2017

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)
Số hiệu:TCVN 11819:2017Loại văn bản:Tiêu chuẩn Việt Nam
Cơ quan ban hành: Bộ Khoa học và Công nghệLĩnh vực: Thông tin-Truyền thông
Năm ban hành:2017Hiệu lực:Đang cập nhật
Người ký:Tình trạng hiệu lực:
Đã biết

Vui lòng đăng nhập tài khoản gói Tiêu chuẩn hoặc Nâng cao để xem Tình trạng hiệu lực. Nếu chưa có tài khoản Quý khách đăng ký tại đây!

Tình trạng hiệu lực: Đã biết
Ghi chú
Ghi chú: Thêm ghi chú cá nhân cho văn bản bạn đang xem.
Hiệu lực: Đã biết
Tình trạng: Đã biết

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. Nhn 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 kim 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. Mu đồ 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 tng

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) Kim 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 cp 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 bn 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 Cht lượng thẩm định, Bộ Khoa học và Công nghệ công bố.

 

KHỐI TRUY NHẬP CÓ ĐIU KIỆN DÙNG TRONG TRUYN HÌNH KTHUẬT S- YÊU CU 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 chun này giải quyết các vn đề 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 chun này mô tả một hệ thng 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 chp nhận và xác nhận, bao gồm cmã hóa và xác thực thiết bị và bn 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à kim nghiệm mà hiện tại chúng chưa có điểm yếu cụ thể nào.

Tiêu chun 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 chun này.

Tiêu chuẩn này được sử dụng kết hợp với quy trình cấp giy 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 chun 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 chun 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 tin (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 du 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ã thhiệ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ữ - Phn 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à Giy 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 chun 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 chun 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 chun 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 chun 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 giy 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ố cht 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)

Giy 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 cp 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 sa đổ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 chun này, các ký tự sau đây được áp dụng:

E {K} (M)

Mã hóa bản tin 'M' sử dụng khóa 'K'

 

D {K} (M)

Giải mã bản tin 'M' sử dụng khóa 'K'

 

P

Khóa công khai

 

Q

Khóa riêng

 

DQ

Khóa riêng thiết bị

 

DP

Khóa công khai thiết bị

 

A {K} (M)

Xác thực của bản tin 'M' với khóa 'K'

 

V {K} (M)

Kiểm tra bản tin 'M' với khóa 'K'

 

AÅB

Toán tử XOR của 'A' và 'B'

 

A I B

Toán tử OR của 'A' và 'B'

 

A II B

Toán tử AND của 'A' và 'B'

 

0x...

Tiền tố này ch thị có một giá trthập lục phân theo sau.

 

0b...

Tiền tố này chthị có một giá trị nhị phân theo sau.

 

3.3  Chữ viết tắt

 

Theo mục đích của tiêu chun này, các chữ viết tắt sau đây được áp dụng:

 

AES

Advanced Encryption Standard

Tiêu chun mã hóa tiên tiến

APDU

Application Protocol Data Unit

Đơn vị dữ liệu giao thức ứng dụng

API

Application Programming Interface

Giao diện lập tnh ứng dụng

APS

Analogue Protection System

Hệ thống bảo vệ tương tự

ASN.1

Abstract Cú pháp Notation One

Ký hiệu cú pháp trừu tượng 1

AV

Audio Video

Âm thanh và hình ảnh

BAT

Bouquet Association Table

Bảng liên kết nhóm dịch vụ

bslbf

Bit serial leftmost bit first

Bit tận cùng bên trái nối tiếp bit đầu

BSM

Basic Service Mode

Chế độ dịch vụ cơ bản

CA

Conditional Access

Truy nhập có điều kiện

CAM

Conditional Access Module

Mô-đun truy nhập có điều kiện

CAS

Conditional Access System

Hệ thống truy nhập có điều kiện

CBC

Cipher Block Chaining

Thuật toán mã hóa khối chuỗi

CC

Content Control

Kiểm soát nội dung

CCK

Content Control Key

Mã khóa kiểm soát nội dung

Cl

Common Interface

Giao diện chung

CICAM

Common Interface Conditional Access Module

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

CICAM_ID

CICAM's unique identification number

Số nhận dạng duy nht của CICAM

CRL

Certificate Revocation List

Danh sách thu hồi giy chứng nhận

CWL

Certificate White List

Danh sách trắng giấy chứng nhận

DES

Data Encryption Standard

Tiêu chuẩn mã hóa dữ liệu

DH

Diffie-Hellman

Diffie-Hellman

DOT

Digital Only Token

Bit nhận biết sử dụng nén đối với nội dung số

DSM-CC

Digital Storage Media - Command and Control

Phương tiện lưu trữ kỹ thuật số - điều khiển và kiểm soát

DTV

Digital Television

Thiết bị truyền hình kỹ thuật số

DVB

Digital Video Broadcast

Truyền hình kỹ thuật số

ECB

Electronic Code Book

Sách mã điện tử

ECM

Entitlement Control Message

Bản tin kiểm soát quyền

EIT

Event Information Table

Bảng thông tin sự kiện

EMI

Encryption Mode Indicator

Chỉ số chế độ mã hóa

EMM

Entitlement Management Message

Bản tin quản lý quyền

Eq.

Equation

Công thức

FQDN

Fully Qualified Domain Name

Tên miền đạt tiêu chuẩn

FTA

Free-To-Air

Truyền hình miễn phí

Host

Host

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

HOST_ID

Host device unique identification number

Số nhận dạng duy nhất thiết bị máy chủ

ICT

Image Constraint Token

Bit nhận biết nén hình ảnh

IV

Initialisation Véc-tơ

Véc-tơ khởi tạo

Key

Key

Mã khóa/ Khóa.

LSB

Least Significant Bit

Bit ít quan trọng nhất

MAC

Message Authentication Code

Mã xác thực bản tin

mjdutc

Modified Julian Date UTC

UTC theo ngày Julian sửa đổi

MMI

Man Machine Interface

Giao diện người máy

MHEG

Multimedia and Hypermedia Experts Group

Nhóm nghiên cứu đa phương tiện và siêu phương tiện

MPEG

Motion Pictures Experts Group

(Chuẩn) Nhóm nghiên cứu hình ảnh động/ MPEG

NIT

Network Information Table

Bảng thông tin mạng

PCMCIA

PC Memory Card International Association

(Chuẩn giao diện) Hiệp hội thẻ nhớ máy tính quốc tế/ PCMCIA

PIN

Personal Identification Number

Snhận dạng cá nhân

PMT

Programme Map Table

Bảng sắp xếp chương trình

PPV

Pay-Per-View

Trả phí khi xem

PKI

Public Key Infrastructure

Hạ tầng khóa công khai

PSI

Program Specific Information

Thông tin cụ thể chương trình

RCT

Redistribution Control Token

Mã kiểm soát phân phối lại

RFC

Request For Comment

(Chuẩn) Đề nghị bình luận/ RFC

ROT

Root Of Trust (i.e. Trust Authority)

Nguồn gốc tin cậy (tức là Tổ chức tin cậy)

RSA

Rivest Shamir Adleman public key cryptographic algorithm

Thuật toán mã hóa mã khóa công khai Rivest Shamir Adleman

RSD

Revocation Signalling Data

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

RSM

Registered Service Mode

Chế độ đăng ký dịch vụ

SAC

Secure Authenticated Channel

Kênh xác thực an toàn

SAK

SAC Authentication Key

Mã khóa xác thực SAC

SDT

Service Descriptor Table

Bảng nhãn mô tả dịch vụ

SEK

SAC Encryption Key

Mã khóa mã hóa SAC

SHA

Secure Hash Algorithm

Thuật toán băm an toàn

SIV

SAC Initialisation Véc-tơ

Vec tơ khởi tạo SAC

SOCRL

Service Operator Certificate Revocation List

Danh sách thu hồi giấy chứng nhận của nhà điều hành dịch vụ

SOCWL

Service Operator Certificate White List

Danh sách trắng giấy chứng nhận của nhà điều hành dịch vụ

SOPKC

Service Operator Public Key Certificate

Giấy chứng nhận mã khóa công khai của nhà điều hành dịch vụ

SMS

Short Message Service (mobile phone)

Dịch vụ nhắn tin ngắn (điện thoại di động)

SRM

System Renewability Message

Bản tin làm mới lại hệ thống

SSAC

Single Source Authenticity Check

Kiểm tra xác thực nguồn gốc đơn

SSU

System Software Update

Cập nhật phần mềm hệ thống

TLF

Tag Length Format

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

TS

Transport Stream

Dòng truyền tải

TSC

Transport Scrambling Control

Kiểm soát xáo trộn truyền tải

UCK

URI Confirmation Key

Mã khóa xác nhận URI

uimsbf

Unsigned integer most significant bit first

Số nguyên không dấu bit quan trọng nhất đầu tiên

URI

Usage Rules Information

Thông tin các quy tắc sử dụng

UTC

Coordinated Universal Time

Giờ phối hợp quốc tế

VOD

Video On Demand

Truyền hình theo yêu cầu

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 kim 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ủ chun 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 chun 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 cp 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 chcó thể xác định xem CICAM ghép vào giao diện chỉ tuân th chun 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 cn.

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

 

Máy chủ

 

Cl

Cl Plus

CICAM

Cl

Hành vi Cl mặc định được mô tả trong EN 50.221

Việc ngăn chặn của máy chủ có thể tùy chọn bảo vệ nội dung được kiểm soát khi được thông báo trong dòng truyền tải truyền hình.

Hành vi Cl mặc định được mô tả trong EN 50221 nếu việc ngăn chặn của máy chủ không được nhà cung cấp dịch vụ truyền hình kích hoạt.

Nội dung được Cl CAM giải mã không được mã hóa lại trên giao diện chung.

Cl Plus

Một số nội dung được kiểm soát có th tùy chọn được giải xáo trộn và truyền đến máy ch dưới sự kiểm soát của hệ thống CA.

Nội dung được Cl Plus CICAM giải mã không được mã hóa lại trên giao diện chung.

Nội dung được kiểm soát không được hin thị trừ khi CICAM và máy chủ đã xác thực và máy chủ hỗ trợ các thuật toán mã hóa được Cl Plus quy định và được CICAM yêu cầu.

Nội dung được kiểm soát được CICAM giải mã được mã hóa lại trên giao diện chung tùy theo giá trị EMI trong URI.

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 bng 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 bo 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 kim soát nội dung CICAM bao gồm ba thành phn hoạt động sau đây:

• Xác thực máy chủ; dựa trên việc trao đổi giy 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) kim 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 bt 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á trcao 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ự xy 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 cp 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 du.

• 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 bi cơ chế kim soát nội dung.

Tiêu chuẩn này mrộ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ế kim soát nội dung.

• URI phiên bản 2 mrộ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 cp 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 cp 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 cp 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 cp 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 cu 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 đó để ci 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 cp 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 tt 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 bng 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 ti 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 tt cmọ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 chun này. Bt 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ơ đồ chra 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ệ bi 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 tc 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 chun này cung cp 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

TT

Mô tả

Tham chiếu đến

Bước # 1 Khởi tạo xác thực - kiểm tra giấy chứng nhận và trao đổi mã khóa DH

1

CICAM kích hoạt quá trình xác thực.

CICAM khi tạo quá trình xác thực khi không có mã khóa xác thực từ liên kết thành công trước. Quá trình xác thực này được giới thiệu trong điều 5.9. Tham chiếu đến mục tham chiếu cột bên để biết thông tin chi tiết đầy đủ.

Điều 6

2

Máy chủ tham gia quá trình xác thực tương hỗ.

Máy chủ kiểm tra dữ liệu giao thức nhận được để xác định xem nó được bắt nguồn từ một CICAM hợp lệ và tham gia quá trình xác thực tương hỗ.

Điều 6

Bước # 2 Khi tạo xác thực - Xác minh khóa xác thực

3

CICAM yêu cầu sự xác thực khóa máy chủ

Điều 6

4

Các CICAM yêu cầu khóa xác thực (AKH) từ máy chủ, để xác định rằng cả CICAM và Máy chủ đã tính toán với cùng một khóa. Máy chủ phản hồi yêu cầu này với khóa xác thực đã được chính nó tính toán.

Bước # 3 Khởi tạo - Thiết lập SAC

5

Thiết lập SAC.

Điều 7

6

Sau khi xác thực thành công CICAM và máy chủ bắt đầu trao đổi dữ liệu và tính mã khóa mã hóa (SEK) và xác thực (SAK) của các bản tin được truyền qua SAC. Dựa vào việc thiết lập các mã khóa SEK và SAK, CICAM phải đồng bộ với máy chủ đ bắt đu sử dụng các mã khóa mới trong khoảng thời gian chờ được xác định trước. SAC được thiết lập bằng cách sử dụng các mã khóa này.

Bước # 4 Khi tạo - Thiết lập mã khóa CC

7

Thiết lập mã khóa CC.

Điều 8

8

Sau khi xác thực thành công, CICAM có thể bắt đầu tính mã khóa CC. Sau khi khi tạo thành công SAC, CICAM có thể thông báo cho máy chủ để tính mã khóa CC. Dựa vào việc thiết lập mã khóa CC, CICAM phải đồng bộ vi máy chủ để bắt đầu tính mã khóa CC mới trong thời gian chờ được xác định trước. Bộ (giải) xáo trộn được khởi tạo bằng cách sử dụng mã khóa CC. Chú ý rằng bước này có thể được thực hiện lặp lại dựa vào việc thiết lập thời gian sống lớn nhất của mã khóa này.

 

Bước # 5 Khởi tạo - Truyền và sử dụng kim soát sao chép nội dung

9

CICAM khởi tạo việc truyền URI info và giấy phép tùy chọn.

CICAM truyền URI và giấy phép tùy chọn phù hợp với những giới hạn kim soát sao chép hiện tại đối với dịch vụ được lựa chọn đến máy chủ. Chú ý rằng bước này có thể được thực hiện lặp lại trong một sự kiện chương trình dựa vào việc thiết lập thực của URI. Xem CHÚ THÍCH 2.

Điều 5.7.4

10

Máy chủ áp dụng các thiết lập của URI, kết hợp việc ghi lại giấy phép và máy chủ xác nhận

Điều 5.7.5.3

11

Sau khi nhận thông tin URI, máy chủ phải trả lời CICAM trong thời gian chờ được xác định trước và sau đó áp dụng các giới hạn kim soát sao chép đối với các giao diện bên ngoài như được quy định trong [6]

 

CHÚ THÍCH:

1. Tham chiếu các đến các điều tham chiếu ở cột bên để biết thông tin chi tiết đầy đủ.

2. Phiên bản URI được sử dụng phải được thương lượng trước xem 5.7.5.1

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

Mã khóa

Mô tả

Được lưu trữ hoặc thay đổi

Được lưu trữ nội bộ hoặc trao đổi

Root cert

Giấy chứng nhận gốc

được lưu trữ (hằng số giấy phép)

được lưu trữ nội bộ (không thể thay thế)

Brand cert

Giy chứng nhận thương hiệu

được lưu trữ (hằng số giấy phép)

được trao đi (không thể thay thế)

Device cert

Giy chng nhận thiết bị

được lưu trữ (hằng số giấy phép)

được trao đổi (không thể thay thế)

pmg_seed

Với mỗi nhân của nhà sản xuất dành cho PRNG

được lưu trữ (hằng số giấy phép)

được lưu trữ nội bộ (không thể thay thế)

DH_p

Mô đun chính Diffie-Hellman

được lưu trữ (hằng số giấy phép)

được lưu trữ nội bộ

DH_g

Mô đun bộ tạo Diffie-Hellman

được lưu trữ (hằng số giy phép)

được lưu trữ nội bộ

DH_q

Hằng s Diffie-Hellman Sophie Germain

được lưu trữ (hằng số giấy phép)

được lưu trữ nội bộ

MDQ

Mã khóa riêng của mô đun

được lưu trữ (hằng số giy phép)

được lưu trữ nội bộ (không thể thay thế)

MDP

Mã khóa công khai của mô đun

được lưu trữ

được trao đi

HDQ

Mã khóa riêng của máy chủ

được lưu trữ (hằng số giấy phép)

được lưu trữ nội bộ (không thể thay thế)

HDP

Mã khóa công khai của máy chủ

được lưu trữ

được trao đi

DHX

Diffie-Hellman nonce (mũ x)

được thay đổi

được lưu trữ nội bộ

DHY

Diffie-Hellman nonce (mũ y)

được thay đổi

được lưu trữ nội bộ

DHPM

Mã khóa công khai Diffie-Hellman của mô đun

được thay đổi

được trao đi

DHPH

Mã khóa công khai Diffie-Hellman của máy chủ

được thay đổi

được trao đổi

DHSK

Mã khóa mật Diffie-Hellman

được lưu trữ

được lưu trữ nội bộ

AKM

Mã khóa xác thực của mô đun

được lưu trữ (trên mô đun)

được lưu trữ nội bộ

AKH

Mã khóa xác thực của máy chủ

được lưu trữ (trên máy chủ)

được trao đi (được bảo vệ)

Ns_Module

Nonce SAC của mô đun

được thay đi

được trao đi

Ns_Host

Nonce SAC của máy chủ

được thay đổi

được trao đổi

SEK

Mã khóa mã hóa SAC

được thay đi

được lưu trữ nội bộ

SAK

Mã khóa xác thực SAC

được thay đổi

được lưu trữ nội bộ

SIV

Vec tơ khởi tạo SAC

được lưu trữ (hằng số giấy phép)

được lưu trữ nội bộ

Kp

Tiền thân của mã khóa

được thay đổi

được trao đổi (được bảo vệ)

CCK

Mã khóa kiểm soát nội dung

được thay đổi

được lưu trữ nội bộ

CIV

Vec tơ khởi tạo CC

được thay đổi

được lưu trữ nội bộ

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 nm 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 cp mã khóa. Các giấy chng 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 bn 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ã bn 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 kho đ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ụ

Chế độ

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

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

Chế độ dịch vụ cơ bản

6

Chế độ đăng ký 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ụ 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 khi 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 bng 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) thể được bỏ qua, và CICAM có thể bt đầ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 bmá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 hi giy 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 hi, 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 bi 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 bi 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 bn mô tả và phải được xác nhận bi 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 cp 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 cp 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 cp 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 cp 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 chun 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 đó nm 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ủ, chun giấy cp 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 hi 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 cp) 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ụ phi đượ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 đó nm ngoài phạm vi tiêu chuẩn này, xem Chuẩn cấp giy 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 cha 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 du 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 du 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 vn 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 bmá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 bthu 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 cp 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 nm 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 giy 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 rng 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.

Ti 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 du. 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 du 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 du. Nó cũng kiểm tra xem:

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

○ Nếu số phiên bản CRLthuộ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ảnthuộc SOCWL bằng ‘số phiên bảnthuộ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 hi; 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ỏ bt 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 phi đượ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 dch 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 chtừ chối dịch vcá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 vcá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 hi 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 bo vệ. CICAM xác định bng 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 gii 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 gii 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)

Các bit kiểm soát xáo trộn truyền

Mô tả

Diễn giải

00

Không giải xáo trộn

Yêu cầu hỗ trợ

01

Xáo trộn bằng mã khóa nội dung DEFAULT

Không được CICAM và máy chủ hỗ trợ

10

Xáo trộn bằng mã khóa nội dung EVEN

Yêu cầu hỗ trợ

11

Xáo trộn bằng mã khóa nội dung ODD

Yêu cầu hỗ trợ

CHÚ THÍCH: Các giới hạn xáo trộn mức TS tuân theo ISO 13818-1 [13].

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 vgiao 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 vcá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 cu 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ủ

Tùy chọn bộ xáo trộn

CICAM

Máy chủ

DES-56-ECB

Bắt buộc

Bắt buộc đối với cmáy chủ SD và HD

AES-128-CBC

Tùy chọn

Chỉ bắt buộc đối với máy chủ HD

Đị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

Mô đun

Máy chủ

Thực hiện

Diễn giải

Không

Không

Dừng CC và đưa ra TS đối với nội dung rõ ràng

"Không" đối với máy chủ hoặc mô đun

DES

DES

Xáo trộn lại TS đầu ra sử dụng DES.

 

DES

AES

Xáo trộn lại TS đu ra sử dụng DES.

 

AES

DES

Xáo trộn lại TS đu ra có thể sử dụng DES.

Xem CHÚ THÍCH 3

AES

AES

Xáo trộn lại TS đầu ra sử dụng AES.

 

CHÚ THÍCH

1. Chủ sở hữu nội dung này có thể chấp nhn sử dụng DES hoặc AES, điều này có nghĩa là nhà cung cp có thể lựa chọn công nghệ để sử dụng các CICAM được DES hoặc AES cho phép.

2. TS đầu ra được xác định trong EN 50221 [7]

3. Hệ thống CA có thể quyết định xem DES là không phù hợp và lựa chọn để không giải xáo trộn nội dung này.

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 ti 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 kim 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 phn 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 kim 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 tt 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 nht đã đượ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 cp 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ị chcó 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 thSCTE41 [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à Chun 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 mi 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ô tbộ xáo trộn và bộ giải xáo trộn AES dành cho tiêu chun này.

Hình 5.12 chỉ ra định dạng cp 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 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 bng s = EAES-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)=EAES-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ơ khi 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)=EAES-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 bng 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 phn đượ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ã ln 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. Để khi tạo, công thức sau được sử dụng:

b(1)=DAES-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á trthô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 cp 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 chun 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 nm 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 giy 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

Trường

Giá trị khởi tạo mặc định

protocol version

0x01

emi_copy_control_info

0b11

aps_copy_control_info

0b00

ict_copy_control_info

0b0

rct_copy_control_info

0b0

rl_copy_control_info

0b000000

Các bit dự phòng

0b0

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

Trường

Giá trị khởi tạo mặc định

protocol version

0x02

emi_copy_control_info

0b11

aps_copy_control_info

0b00

ict_copy_control_info

0b0

rct_copy_control_info

0b0

dot_copy_control_info

0b0

rl_copy_control_info

0b00000000

Các bit dự phòng

0b0

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á trmặ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 bn 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ủ phi 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ủ chsau 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 rng bt 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 nm 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)

TT

Mô tả

Tham chiếu đến

1

Kết hợp URI với chương trình.

URI được kết hợp với nội dung này (dịch vụ hoặc sự kiện DVB). Quá trình chính xác; bao gồm các giá trị URI thay thế nằm ngoài phạm vi tiêu chuẩn này.

 

2

Cung cấp URI ví dụ trong EMM (nằm ngoài phạm vi tiêu chuẩn này).

Việc cung cấp URI thường được hệ thống CA bảo vệ giữ sự kết hợp giữa URI và schương trình. Quá trình cung cp chính xác này nằm ngoài phạm vi tiêu chuẩn này.

 

3

CICAM tạo bn tin URI.

CICAM tính uri_confirm để xác thực xác nhận của máy chủ đã nhận được (CHÚ THÍCH 5), vì:

uri_confirm = SHA256 (uri_ message ǁ UCK)

trong đó:

• UCK = SHA256 (SAK)

Giá trị uri_confirm được lưu trữ nội bộ để so sánh trong bước 8.

CICAM phải tạo một cc_sac_data_req APDU dành cho bản tin URI này, bao gồm:

• uri_message,

• program_number

Điều 5.7.5.1

4

CICAM khởi tạo thời gian chờ 1 giây.

CICAM khởi tạo thời gian chờ 1 giây để thủ tục URI phải hoàn thành. (CHÚ THÍCH 1)

Hình 5.11

5

CICAM truyền bản tin SAC với tải URI

CICAM truyền một bản tin SAC với tải từ bước 3 và truyền bản tin này đến máy chủ. (CHÚ THÍCH 2).

Điều 7.3 và 11.3.1

6

Máy chủ kiểm tra bản tin.

Sau khi máy chủ kiểm tra bản tin SAC xem có đúng không thì máy chủ lấy giá trị URI và số chương trình.

 

7

Máy chủ truyền bản tin SAC với xác nhận URI

Máy chủ kiểm tra xem nó có hỗ trợ phiên bản URI mà CICAM yêu cầu. Máy chủ xác nhận việc cung cấp URI bằng cc_sac_data_cnf APDU, bao gồm

• uri_confirm

và sử dụng SAC đề truyền bản tin này đến CICAM. (CHÚ THÍCH 2)

Máy chủ tính uri_confimn theo cách giống như CICAM trong bước 3 trên. Không trả lời sẽ dẫn đến không có hệ thống bảo vệ sao chép và thiết lập URI về giá tr mặc định (CHÚ THÍCH 3 & 4).

Điều 7.3 và 11.3.1

8

CICAM kiểm tra xác nhận của máy chủ.

CICAM so sánh uri_confirm nhận được từ máy chủ với giá trđược tính trong bước 3 ở trên.

Giá trị này không tương đương sẽ dẫn đến không có hệ thống bảo vệ sao chép và thiết lập URI về giá trị mặc định (CHÚ THÍCH 3 & 4).

 

9

Sử dụng các thiết lập kiểm soát sao chép

Máy chủ phải kiểm soát các đầu ra của nó dựa vào URI hợp lệ ngay lập tức.

 

CHÚ THÍCH:

1. Nếu các bước trên không được hoàn thành trước khi hết thời gian chờ 1 giây thì CICAM phải không cho phép giải xáo trộn CA nội dung được bảo vệ sao chép (tức là EMI ≠ 0x0) đối với chương trình MPEG kết hợp cho tới khi giao thức cung cp URI hoàn thành thành công. Khi giao thức này hoàn thành thì CICAM phải chờ 1 giây trước khi giao thức URI này được khởi tạo lại.

2. Xem điều 7.2 để biết cách dữ liệu của giao thức URI này được đóng gói vào bản tin SAC.

3. Máy chủ phải áp dụng các thiết lập URI mặc định. Các giá trị URI mặc định được quy đnh trong điều 5.7.4.

4. Tham chiếu điều 5.4.3 và phụ lục F để biết thông tin chi tiết về cơ chế báo cáo lỗi chung.

5. Đu vào được gắn tùy theo SHA-256. Tham chiếu FIPS 180-3 [3]. Việc thực hiện SHA nên tuân theo danh sách hợp lệ SHS. Xem danh sách hợp lệ SHS [11].

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ả li 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 bn URI nào sử dụng, quá trình chính xác này nm 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 bn 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 thy tổ hợp

Cú pháp bản tin URI phiên bn 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

Trường

Độ dài

Kiu

uri_message() {

 

 

     protocol_version

8

uimsbf

     aps_copy_control_info

2

uimsbf

     emi_copy_control_info

2

uimsbf

     ict_copy_control_info

1

uimsbf

     rct_copy_control_info

1

uimsbf

     reserved for future use

4

uimsbf

     r1_copy_control_info

6

uimsbf

     reserved for future use

40

uimsbf

}

 

 

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

Trường

Độ dài

Kiểu

uri_message() {

 

 

     protocol_version

8

uimsbf

     aps_copy_control_info

2

uimsbf

     emi_copy_control_info

2

uimsbf

     ict_copy_control_info

1

uimsbf

     if (emi_copy_control_info == 00) {

 

 

     rct_copy_control_info

     }

     else {

1

uimsbf

 

 

          reserved = 0

     }

1

uimsbf

 

 

     reserved for future use

1

uimsbf

     if (emi_copy_control_info == 11) {

1

 

     dot_copy_control_info rl_copy_control_info

     }

     else {

8

uimsbf

 

 

 

 

          reserved = 0x00

9

uimsbf

     }

 

 

     reserved for future use

40

uimsbf

}

 

 

5.7.5.3. Mã hóa và ngtrol_info rl_copy_contr

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

Bảng 5.12: Giá trcho phép của protocol_version

Nội dung

Ý nghĩa

Diễn giải

0x00

Forbidden

không được sử dụng trong tiêu chun này

0x01

Giao thức URI phiên bản 1

Bản quy định kỹ thuật phiên bản 1.2

0x02

Giao thức URI phiên bản 2

Bn quy định kỹ thuật phiên bản 1.3

0x03-0xFF

Dự phòng

 

CHÚ THÍCH: Thiết btuân theo tiêu chun này phải nhận biết được giá trị 0x02 và bỏ qua các bn tin URI có giá trprotocol_version không được hỗ trợ.

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

Nội dung

Giá trị nhị phân

Diễn giải

0x0

00

Tắt mã hóa bảo vệ sao chép

0x1

01

Bật quá trình AGC, tắt chia tách cụm

0x2

10

Bật quá trình AGC, bật chia tách cụm 2 đường

0x3

11

Bật quá trình AGC, bật chia tách cụm 4 đường

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á trcho phép của emi_copy_control_info

Nội dung

Giá trị nhị phân

Diễn giải

0x0

00

Việc sao chép không bị cấm

0x1

01

Việc sao chép thêm không được cho phép

0x2

10

Việc sao chép được cho phép

0x3

11

Việc sao chép bị cấm

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 phn 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

Nội dung

Giá trị nhị phân

Diễn giải

0x0

0

Không sử dụng nén hình ảnh

0x1

1

Yêu cầu nén hình ảnh

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

Nội dung

Giá trị nhị phân

Diễn giải

0x0

0

Không sử dụng kiểm soát phân phối lại. Giá trị mặc định.

0x1

1

Sử dụng kiểm soát phân phối lại.

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ự.

Bng 5.17: Giá trị cho phép của dot_copy_control_info

Nội dung

Giá trị nhị phân

Diễn giải

0x0

0

Không sử dụng nén đối với nội dung số (mặc định)

0x1

1

Chsử dụng nén đối với nội dung số; cm đưa ra trên các đầu ra video tương tự.

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

Nội dung

Giá trị nhị phân

Diễn giải

0x00

000000

Áp dụng giá trị giới hạn duy trì mặc định 90 phút

0x01

000001

Áp dụng giá trị giới hạn duy trì 6 giờ

0x02

000010

Áp dụng giá trị giới hạn duy trì 12 giờ

0x03-0x3F

000011-111111

Áp dụng giá trị giới hạn duy trì là bội số 1 đến 61 lần của 24 giờ tùy theo giá trị nhphân

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ội dung

Giá trị nhị phân

Diễn giải

0x00

00000000

Áp dụng giá trị giới hạn duy trì mặc định 90 phút

0x01

00000001

Áp dụng giá trị giới hạn duy trì 6 giờ

0x02

00000010

Áp dụng giá trị giới hạn duy trì 12 giờ

0x03-0xFE

00000011-11111110

Áp dụng giá trị giới hạn duy trì là bội số 1 đến 252 lần của 24 giờ tùy theo giá trị nhphân

0xFF

11111111

Thời gian duy trì không bị giới hạn

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ủ

Máy chủ

CICAM

Trạng thái

EMI>0

EMI=0

Cl Plus

DVB Cl

 

DVB Cl (CHÚ THÍCH 1)

DVB Cl

DVB Cl

Cl Plus

 

Không giải xáo trộn (CHÚ THÍCH 2)

DVB Cl (CHÚ THÍCH 4)

Cl Plus

Cl Plus

Đã xác thực

Giải xáo trộn + CC (CHÚ THÍCH 4)

Giải xáo trộn

Cl Plus

Cl Plus

SAC không thành công

Không giải xáo trộn

DVB Cl (CHÚ THÍCH 4)

Cl Plus

Cl Plus

CCK không thành công

Không giải xáo trộn

DVB Cl (CHÚ THÍCH 4)

Cl Plus

Cl Plus

CICAM bị hủy b

Không giải xáo trộn

Không giải xáo trộn

Cl Plus

Cl Plus

Máy chủ bị hủy bỏ

CICAM Pass-through (CHÚ THÍCH 3)

CICAM Pass-through (CHÚ THÍCH 3)

Cl Plus

Cl Plus

Xác thực không thành công

Không giải xáo trộn

Không giải xáo trộn

CHÚ THÍCH:

1. Chkhi nhãn mô t Cl Plus không có trong SDTActual.

2. CICAM phải phát hiện EMI >0 và không được giải xáo trộn.

3. Nội dung được truyền qua CICAM không bị thay đổi.

4. Nhà điều hành dịch v và CAS có thể lựa chọn dựa vào các điều kiện kiểm soát nội dung để giải xáo trộn nội dung sang thiết bị DVB Cl

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 ni 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 ca. 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ể khi 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 mmộ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 kim 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ị; Giy 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 du 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 cp chuỗi của giy 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 du của giy 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 du.

• 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 bn tin xác nhận từ nhà điều hành dịch vụ, liệt kê các ID của thiết btừ 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 để tha 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á trriê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ệ bng đó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 gi 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 kim tra xác nhận đóng dấu bng 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 cp cho một giy phép tại thời điểm ghi lại. Máy chủ phải kết hợp giy 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 giy 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ì giy phép được kết hợp này được truyền lại cho CICAM đã tạo ra giy phép mà không có bất kỳ sự thay đổi. CICAM kiểm tra giy 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ế giy 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 khi 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 khi 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 cp 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 Khi 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 bt 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 giy 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 chcung 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 giy phép này đến CICAM ghi lại nội dung gốc này để đánh giá. Giy 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 bn 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 chuyn đổi các bộ đệm chế độ tạm dng vào một bản ghi thì sau đó tt 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 du 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ẽ gi 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í mi 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ệ thng 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 cp việc đánh giá độ tui trong trường hợp này nằm ngoài phạm vi của tiêu chun 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 kim 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 rng 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 bmá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 bt 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 chdà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 cp trong các khả năng của CICAM PIN, trong trường hợp này, máy chủ cung cp một giao diện người sử dụng bn đị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 cp 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ỉ hin 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 trvề 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 cp 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 qun 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 ccá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 cp trong các khả năng của CICAM PIN, trong trường hợp này máy chủ cung cp một màn hình hiển thị bn địa để nhập PIN.

CICAM có thể cung cp 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 cp trong các khả năng của CICAM. Máy chủ không cần cung cp một giao diện bn đị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 dch 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 trvề trạng thái trong cc_PIN_reply (). CICAM thực hiện việc qun 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 cp 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 chuyn đế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 khi 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 cp việc truy nhập được cha mẹ kiểm soát đối với nội dung. CAS có thcó đượ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 cp 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 để khi 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 cp 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à gi 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 nhp 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 cp 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 cp 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 chra 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 bn 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ủ gi 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 cp để 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 cp khả năng lưu trữ một mã PIN để sử dụng như một bộ phận của bản tin khi 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 kim 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, giy 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 sp 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 ti. 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 tvị 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à giy 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 giy 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 ý rng 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 phi, 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 btấ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 bt 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 gim 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 tt 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 vtrí như ban đầu, làm thay thế giy phép và URI hiện tại. URI mi 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 vi 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 giy 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 giy 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 chp 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 chun 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

TT

Mô tả

Tham chiếu đến

1

Gán SRM đúng (nằm ngoài phạm vi tiêu chuẩn này).

SRM đúng được gán cho tổ hợp máy chủ CICAM. Quá trình chính xác này nằm ngoài phạm vi tiêu chun này.

 

2

Cung cấp SRM (nằm ngoài phạm vi tiêu chun này).

Việc cung cấp SRM thường được hệ thống CA bảo vệ hoặc được cung cấp đến CICAM bằng các cách khác (ví dụ: nạp trước). Quá trình cung cấp chính xác này nằm ngoài phạm vi tiêu chuẩn này.

 

3

CICAM tạo bản tin.

CICAM tính datafile_confirm để xác thực xác nhận của máy chủ đã nhận được (CHÚ THÍCH 3):

datafile_confirm □□□SHA256 (datafile ǁ UCK)

trong đó:

• datafile là tập tin SRM,

• UCK = SHA256 (SAK).

Giá trị datafile_confirm được lưu trữ nội bộ để so sánh trong bước 8.

CICAM phải tạo cc_sac_data_req APDU dành cho bản tin của tập tin dữ liệu (SRM), bao gồm:

• tập tin dữ liệu SRM (datatype_id = srm_data).

điều 11.3.5

4

CICAM khởi tạo thi gian chờ 10 giây.

CICAM khởi tạo thời gian chờ 10 giây để thủ tục truyền dữ liệu SRM phải hoàn thành. (CHÚ THÍCH 1)

 

5

CICAM truyền bản tin SAC với tải tập tin dữ liệu SRM.

CICAM truyền bn tin SAC với tải từ bước 3 và truyền bn tin này đến máy chủ. (CHÚ THÍCH 2).

điều 7.3 and 11.3.1

6

Máy chủ kiểm tra bản tin

Sau khi máy chủ kiểm tra bản tin là đúng thì máy chủ tách ly tập tin dữ liệu SRM. Máy chủ có thể truyền tập tin dữ liệu SRM đến một chức năng sử dụng nào đó nằm ngoài phạm vi tiêu chuẩn này (trong trường hợp HDCP).

điều 7.4

7

Máy chủ truyền bn tin SAC với xác nhận của tập tin dữ liệu SRM.

Máy chủ tính datafile_confirm theo cách giống như CICAM đã tính trong bước 3.

Máy chủ xác nhận việc cung cấp tập tin dữ liệu SRM bằng cc_sac_data_cnf APDU, bao gồm

• datafile_confirm (datatype_id = datatransfer_confirm)

• trạng thái

và sử dụng SAC để truyền bản tin này đến CICAM. (CHÚ THÍCH 2)

Trả lời không thành công dẫn đến việc truyền tập tin dữ liệu này không thành công (CHÚ THÍCH 1).

điều 7.3, 11.3.1 and 11.3.5

8

Kiểm tra xác nhận của máy chủ.

CICAM so sánh datafile_confirm nhận được từ máy chủ với giá trị được tính trong bước 3 trên.

Việc không tương đương dẫn đến việc truyền tập tin dữ liệu này không thành công và có thể được CICAM theo dõi. (CHÚ THÍCH 1)

 

9

Áp dụng dữ liệu SRM (nằm ngoài phạm vi tiêu chun này).

Việc áp dụng tập tin dữ liệu SRM nm ngoài phạm vi tiêu chuẩn này.

 

CHÚ THÍCH:

1. Nếu các bước trên không được hoàn thành trước khi hết thời gian ch 10 giây thì CICAM phải xem là việc truyền tập tin d liệu này không thành công. Các hành vi tiếp theo của CICAM nằm ngoài phạm vi tiêu chun này.

2. Tham chiếu điều 7.2 để biết cách dữ liệu SRM được đóng gói vào bản tin SAC.

3. Đầu vào được gắn tùy theo SHA-256. Tham chiếu FIPS 180-3 [3]. Việc thực hiện SHA nên tuân theo danh sách hợp lệ SHS. Xem danh sách hợp lệ SHS [11].

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 rng 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 du đượ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 du đượ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 du 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 du 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 bng 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á trvớ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 cn 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à khi 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 rng CICAM không lưu giữ một AKM hợp lệ.

Hình 6.2 - Biu đồ 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

TT

Mô tả

Tham chiếu đến

1

CICAM phải m một phiên dành cho tài nguyên kiểm soát nội dung

điều 11.3

2

Máy chủ phải xác nhận bằng một trả lời. Việc mở một phiên hợp lệ không thành công dẫn đến hệ thống kiểm soát nội dung không thành công

điều 11.3

3

CICAM phải gửi cc_open_req APDU đến máy chủ.

điều 11.3.1.1

4

Máy chủ phải xác nhận bằng cc_open_cnf APDU, bao gồm:

cc_system_id_bitmask

điều 11.3.1.2

5

CICAM phải gửi cc_data_req APDU đến máy chủ, bao gồm:

• nonce (tức là auth_nonce).

• Các yêu cầu đối với các datatype ID được máy chủ cung cấp được liệt kê trong điều tham chiếu đến cột bên.

điều 11.3.3.2

6

Máy chủ phải xác nhận bằng cc_data_cnf APDU, bao gồm:

• Mã khóa công khai DH của máy chủ (DHPH, tham chiếu điều 6.2.3.2),

• Đóng dấu A (tham chiếu đến điều 6.2.3),

• Giy chứng nhận thương hiệu của máy chủ (Host_BrandCert, tham chiếu đến điều 9.2),

• Giấy chứng nhận thiết bị của máy chủ (Host_DevCert, tham chiếu đến điều 9.2).

Việc trả lời không thành công bằng cc_data_cnf dẫn đến hệ thống kiểm soát nội dung không thành công; Điều này có thể xảy ra khi máy chủ không kiểm tra dữ liệu nhận được của CICAM (CHÚ THÍCH 2).

điều 11.3.3.2

7

CICAM phải theo dõi bằng cc_data_req APDU, bao gồm:

• Mã khóa công khai DH của CICAM (DHPM, tham chiếu đến điều 6.2.3.2),

• Đóng du B (tham chiếu đến điều 6.2.3),

• Giy chứng nhận thương hiệu của CICAM (CICAM_BrandCert, tham chiếu đến điều 9.2),

• Giấy chứng nhận thiết bị của CICAM (CICAM_DevCert, tham chiếu đến điều 9.2).

• Các yêu cầu đối với các datatype ID được máy chủ cung cấp được liệt kê trong điều tham chiếu đến trong cột bên.

Việc trả lời không thành công bng cc_data_req dẫn đến hệ thống kiểm soát nội dung không thành công; Điều này có thể xảy ra khi CICAM không kiểm tra dữ liệu nhận được của máy chủ (CHÚ THÍCH 2).

điều 11.3.3.2

8

Máy chủ phải xác nhận bằng cc_data_cnf APDU, bao gồm:

• Trạng thái của máy chủ.

Việc trả lời không thành công bằng cc_data_cnf dẫn đến hệ thống kiểm soát nội dung không thành công; Điều này có thể xảy ra khi máy chủ không kiểm tra dữ liệu nhận được của CICAM (CHÚ THÍCH 2).

điều 11.3.3.2

9

CICAM phải gửi cc_data_req APDU đến máy chủ để yêu cầu mã khóa xác thực của máy chủ (AKH, tham chiếu đến điều 6.2.3.4), bao gồm:

• Yêu cầu đối với datatype ID của AKH (được quy định trong điều H.1).

điều 11.3.3.3

10

Máy chủ phải xác nhận bằng cc_data_cnf APDU, bao gồm:

• AKH, hợp lệ hoặc không hợp lệ (tham chiếu đến điều 6.2.3.4).

Trả lời không thành công trong thời gian 5 giây bằng cc_data_cnf dẫn đến hệ thống kiểm soát nội dung không thành công (CHÚ THÍCH 2).

điều 11.3.3.3

11

CICAM phải so sánh AKH này với AKM mới được tính. Nếu chúng không giống nhau thì dẫn đến hệ thống kiểm soát nội dung không thành công (CHÚ THÍCH 2).

 

12

Trong chế độ đăng ký dịch vụ, CICAM có thể khởi tạo một tương tác đăng ký.

điều 5.5

14

Người sử dụng đầu cuối có thể gửi các ID của thiết bị đến nhà điều hành dịch vụ. Xem điều 5.4.2.

 

16

Nhà điều hành dịch vụ có th kim tra xem các ID của thiết bị không bị SOCRL thu hồi. Nhà điều hành dịch vụ có thể áp dụng các phương pháp khác để xác định xem các ID của thiết bị được báo cáo có tin cậy ví dụ kiểm tra xác thực v.v... Cơ chế chính xác được sử dụng này nằm ngoài phạm vi tiêu chuẩn này, nhưng nếu sử dụng SOCRL thì nó phải tuân thủ điều 5.5.

 

17

Dựa vào quyết định của nhà điều hành dịch vụ, thợp CICAM/máy chủ có thể được sử dụng hoặc bị thu hồi bằng một cách bt kỳ nào ví dụ một bản tin riêng được hệ thống CA mạng bảo vệ.

 

CHÚ THÍCH

1. Tham chiếu phụ lục H để biết tổng quan các thông số liên quan.

2. Hành vi không thành công của hệ thng kiểm soát nội dung được trình bày trong điều 6.1 và hình 6.1, bước 20. Tham chiếu đến điều 5.4.3 và phụ lục F để biết thông tin chi tiết về cơ chế báo cáo lỗi chung.

6.2.2. Các điều kiện xác thực

Các giới hạn sau đây được định nghĩa trong phần này:

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

Giới hạn

Mô tả

Quy định

Nonce retry

Số lần lớn nht CICAM cố th tạo một nonce (mã dùng 1 lần) hợp lệ

3

Các điều kiện xác thực của CICAM được thể hiện trong hình 6.3 được mô tả dưới đây:

Lưu ý: Tham khảo Bảng 6.3 để biết chi tiết về các tính toán và Bảng 6.1 để biết chi tiết về việc trao đổi bản tin.

1) Tài nguyên CC và phiên phải được mở trước khi CICAM bắt đầu thủ tục xác thực này.

2) CICAM khởi tạo một giao thức nonce "auth_nonce".

3) auth_nonce phải có một độ dài hợp lệ được liệt kê trong Phụ lục H, Bng H.1. Nếu đây không phải là trường hợp mà CICAM cố thử cho đến khi nó đạt đến giá trị Nonce retry giới hạn (xem Bảng 6.2). Nếu đạt giới hạn cố th thì việc xác thực thất bại và CICAM tiếp tục với bước 23.

4) CICAM gi auth_nonce đến máy chủ và yêu cầu dữ liệu tr về trong bản tin xác nhận.

5) CICAM chờ đợi cho đến khi nó nhận được xác nhận từ máy chủ chứa các thông số được yêu cầu.

6) CICAM kiểm tra xem các giấy chng nhận nhận được từ máy chủ có hợp lệ bng cách kiểm tra SSAC. Nếu không hợp lệ, việc xác thực thất bại và CICAM tiếp tục với bước 23.

7) CICAM kim tra xem đóng dấu A nhận được từ máy chủ có hợp lệ bằng cách kiểm tra SSAC. Nếu không hợp lệ, việc xác thực thất bại và CICAM tiếp tục với bước 23.

8) CICAM kiểm tra xem mã khóa DHPH nhận được từ máy chủ có hợp lệ bằng cách kiểm tra độ dài theo Phụ lục H, Bng H.1 và giá tr theo kiểm tra kiểm soát trong điều 6.2.3.2. Nếu không hợp lệ, việc xác thực tht bại và CICAM tiếp tục với bước 23.

9) CICAM tạo ra một nonce ngẫu nhiên DHY để sử dụng trong các tính toán DH.

10) CICAM tính một mã khóa công khai DH DHPM.

11) CICAM kiểm tra xem mã khóa DHPM được tính toán có hợp lệ bằng cách kiểm tra độ dài theo Phụ lục H, Bng H.1 và giá trị theo kiểm tra kiểm soát trong điều 6.2.3.2. Nếu không hợp lệ, việc xác thực thất bại và CICAM tiếp tục với bước 23.

12) CICAM tạo ra một đóng du duy nht B đối với dữ liệu được trao đi với máy chủ.

13) CICAM gửi dữ liệu giao thức đến máy chủ với yêu cầu nhận được trạng thái của máy chủ.

14) CICAM chờ đợi cho đến khi nhận được xác nhận từ máy chủ với trạng thái của nó.

15) CICAM kiểm tra xem trạng thái của máy chủ là OK. Nếu không OK, việc xác thực tht bại và CICAM tiếp tục với bước 25.

16) CICAM tính các mã khóa DHSK và AKM.

17) CICAM kiểm tra xem DHSK và AKM có hợp lệ theo điều 6.2.3.3 và 6.2.3.4. Nếu không hợp lệ, việc xác thực tht bại và CICAM tiếp tục với bước 23.

18) CICAM yêu cầu mã khóa AKH của máy chủ.

19) CICAM phải nhận được trả lời của máy chủ trong vòng 5 giây. Nếu không nhận được trong vòng 5 giây, việc xác thực thất bại và CICAM tiếp tục với bước 23.

20) CICAM kiểm tra xem trả lời này có chứa một mã khóa AKH hợp lệ. Nếu mã khóa có tất cả các số là không thì AKH được xem là không hợp lệ và việc xác thực không thành công, CICAM tiếp tục với bước 23.

21) CICAM kiểm tra AKH đã nhận được từ máy chủ có phù hợp với AKM của CICAM. Nếu không phù hợp, việc xác thực thất bại và CICAM tiếp tục với bước 23.

22) CICAM hoàn thành việc xác thực thành công.

23) CICAM có thể khởi tạo một xác thực thất bại tương tác MMI.

24) Xác thực thất bại.

CHÚ THÍCH: Giới hạn số ln cố thử được quy định trong bảng 6.2

Hình 6.3: Tổng quan các điều kiện xác thực phía CICAM.

Hình 6.4 - Tổng quan các điều kiện xác thực phía mặt chủ

Các điều kiện xác thực của máy chủ được thể hiện trong hình 6.4 được mô tả dưới đây:

Lưu ý: Tham khảo Bảng 6.2 để biết chi tiết về các tính toán và Hình 6.2 để biết chi tiết về việc trao đổi bản tin.

1) Phiên và tài nguyên CC được mở thành công.

2) Máy chủ nhận được nonce từ CICAM.

3) Máy chủ kiểm tra xem nonce nhận được có hợp lệ như được liệt kê trong Phụ lục H, Bảng H.1. Nonce này được sử dụng trong suốt giao thức xác thực.

4) Máy chủ tạo ra một nonce ngẫu nhiên DHX để sử dụng trong các tính toán DH.

5) Máy chủ tính một mã khóa công khai DH DHPH.

6) Máy chủ kiểm tra xem mã khóa DHPH được tính có hợp lệ bằng cách kiểm tra độ theo Phụ lục H, Bảng H.1 và giá trị theo kiểm tra kiểm soát trong điều 6.2.3.2.

7) Máy chủ tạo một đóng dấu A duy nhất đối với dữ liệu được trao đi với CICAM.

8) Máy chủ gửi dữ liệu giao thức đến CICAM.

9) Máy chủ chờ đợi tr lời t CICAM chứa các thông số được yêu cầu để hoàn thành việc xác thực.

10) Máy chủ thiết lập trạng thái của máy chủ là lỗi.

11) Máy chủ kiểm tra giấy chứng nhận nhận được từ CICAM xem có hợp lệ bằng cách kim tra SSAC.

12) Máy chủ kiểm tra xem đóng dấu B nhận được từ CICAM có hợp lệ bằng cách kiểm tra SSAC.

13) Máy chủ kiểm tra xem mã khóa DHPM nhận được từ CICAM có hợp lệ bằng cách kiểm tra độ dài theo Bảng H.1 và giá trị theo kiểm tra kim soát trong điều 6.2.3.2.

14) Máy chủ gửi một xác nhận với trạng thái địa phương.

15) Máy chủ thiết lập trạng thái máy chủ là ok.

16) Máy chủ gửi xác nhận trạng thái địa phương.

17) Máy chủ tính các mã khóa DHSK và AKH.

18) Máy chủ kiểm tra xem DHSK và AKH có hợp lệ theo điều 6.2.3.3 và 6.2.3.4.

19) Các mã khóa hợp lệ phải có nghĩa là việc xác thực máy chủ là thành công nhưng chưa hoàn thành.

20) Các mã khóa không hợp lệ hoặc có bất kỳ lỗi nào khác trong giao thức xác thực phải có nghĩa là việc xác thực đã thất bại.

21) Máy chủ nhận được yêu cầu từ CICAM thông báo mã khóa AKH của máy chủ.

22) Máy chủ phải xác nhận với giá trị của AKH. Một mã khóa AKH không hợp lệ có tất cả các số là không. Lưu ý rằng CICAM có thể cố th, lặp lại bước 21 cho đến bước 22.

23) Việc xác thực hoàn thành.

6.2.3. Các tính toán mã khóa xác thực

Nếu một mã khóa xác thực không phù hợp (xem điều 6.1.2) hệ thống thực hiện một phiên xác thực được mô tả trong hình 6.5.

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

Hình 6.5 - Biểu đồ trình tự tính toán mã khóa xác thực

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

Bảng 6.3 - Tính toán mã khóa xác thực

TT

Mô tả

Tham chiếu đến

0

Khi bắt đầu máy chủ thực hiện kiểm tra xem các thông số DH có hợp lệ.

điều 6.2.3.1

1

CICAM phải tạo nonce 256 bit ngẫu nhiên (auth_nonce), nó được bao gồm trong đóng du chứa các thông số trao đổi của giao thức DH 3 pass. Nonce này phải được một PRNG phù hợp tạo ra.

Phụ lục A

2

CICAM phải gửi auth_nonce đến máy chủ bằng cách sử dụng một bản tin APDU thích hợp.

điều 11.3.2.2

3

Máy chủ phải kiểm tra xem thông số auth_nonce nhận được có kích thước đúng không (256 bit).

Phụ lục A

4

Máy chủ phải tạo một giá trị ngẫu nhiên dành cho số mũ x DH. Giá trị x (DHX) phải được một PRNG phù hợp tạo ra.

Phụ lục A

5

Máy chủ phải tính mã khóa công khai DH của máy chủ (DHPH).

điều 6.2.3.2

6

Máy chủ phải tạo đóng dấu A trên auth_nonce and DHPH này, sao cho:

message_A = (version ǁ msg_label ǁ auth_nonce ǁ DHPH)

signature_A = RSASSA-PSS-SIGN(HDQ, message _ A)

trong đó:

• RSASSA-PSS phải được sử dụng như được tham chiếu trong CHÚ THÍCH 2.

• HDQ là mã khóa riêng của thiết bị được quy định trong điều 5.3.

• version = 0x01 và msg_label = 0x2.

• Auth_nonce giống giá trị nhận được trong bước 3.

Phụ lục I

7

Máy chủ phải gửi đóng dấu A và mã khóa DHPH, cùng với giấy chứng nhận thương hiệu của máy chủ và giấy chứng nhận thiết bị của máy chủ đến CICAM.

điều 11.3.3.2

8

CICAM phải kiểm tra các thông số nhận được sau:

a) CICAM phải kiểm tra đóng dấu trên các giấy chứng nhận.

b) CICAM phải kiểm tra đóng dấu A, đ:

message_ A = (version ǁ msg_ label ǁ auth_ nonce ǁ DHPH)

RSASSA- PSS - VERIFY(HDP, message_ A, signature_ A) = TRUE

trong đó:

• RSASSA-PSS phải được sử dụng như được tham chiếu trong CHÚ THÍCH 2.

• HDP là mã khóa riêng của thiết bị nhận được trong bước 7.

• version = 0x01 và msg_label = 0x2.

• Auth_nonce giống giá trị được tạo ra trong bước 1.

• DHPH giống giá trị nhận được trong bước 7.

• TRUE có nghĩa là ‘đóng dấu hợp lệ’

c) CICAM phải kiểm tra để:

1 <DHPH <DH_p and DHPHDH-q mod DH_p = 1

điều 9.4

9

CICAM phải tạo ra một giá trị ngẫu nhiên dành cho số mũ y DH. Giá trị y (DHY) phải được một PRNG phù hợp tạo ra.

Phụ lục A

10

CICAM phải tính mã khóa công khai DH của CICAM (DHPM).

điều 6.2.3.2

11

CICAM phải tạo ra đóng dấu B trên mã khóa DHPM và các thông số được trao đi auth_nonce và DHPH, sao cho:

message _ B = (versionǁ msg _ label ǁ auth _ nonce ǁ DHPH ǁ DHPM) signature_ B = RSASSA - PSS - SIGN(MDQ, message _ B) trong đó:

Phụ lục I

 

• RSASSA-PSS phải được sử dụng như được tham chiếu trong CHÚ THÍCH 2

• MDQ là mã khóa riêng của thiết bị được quy định trong điều 5.3.

• version = 0x01 và msg_label = 0x3.

• Auth_nonce giống giá trị được tạo ra trong bước 1.

điều 5.3

12

CICAM gửi đóng dấu B và mã khóa DHPM, cùng với giy chứng nhận thương hiệu của CICAM và giấy chứng nhận thiết bị của CICAM đến máy chủ bằng cách sử dụng một bn tin APDU thích hợp.

điều 11.3.3.2

13

Máy chủ phải kiểm tra các thông số nhận được sau:

a) Máy chủ phải kiểm tra đóng dấu trên các giấy chứng nhận.

b) Máy chủ phải kiểm tra đóng dấu B, sao cho:

message _ B = (versionǁ msg _ label ǁ auth _ nonce ǁ DHPH ǁ DHPM)

RSASSA - PSS - VERIFY(MDP, message _ B, signature_ B) = TRUE

trong đó:

• RSA phải được sử dụng như được tham chiếu trong CHÚ THÍCH 2.

• MDP là mã khóa riêng của thiết bị nhận được trong bước 12.

• Version = 0x01 và msg_label = 0x3.

• Auth_nonce giáng giá trị nhận được trong bước 3.

• DHPH giống giá trị được tạo ra trong bước 5.

• DHPM giống giá trnhận được trong bước 10.

• TRUE có nghĩa là ‘đóng dấu hợp lệ’

c) Máy chủ phải kiểm tra để: 1 < DHPM < DH _ p và DHPM DH-q mod DH _ p=1

d) Máy chủ phải xác nhận nhãn nhận dạng thương hiện của CICAM có trong giấy chứng nhận và là một số nguyên trong dài từ 1 đến 65535

điều 9.4

14

Máy chủ phải xác nhận nó sẵn sàng gửi trạng thái bằng cách sử dụng một bản tin APDU thích hợp.

điều 11.3.3.2

15

CICAM phải tính và lưu trữ mã khóa DHSK.

điều 6.2.3.3

 

CICAM phải tính và lưu trữ mã khóa AKM.

điều 6.2.3.4

16

Máy chủ phải tính và lưu trữ mã khóa DHSK.

điều 6.2.3.3

 

Máy chủ phải tính và lưu trữ mã khóa AKH.

điều 6.2.3.4

17

CICAM phải bắt đầu việc kiểm tra xác thực (bước 2 trong quá trình xác thực) bằng cách gửi một yêu cầu mã khóa xác thực hiện tại AKH đến máy chủ bằng cách sử dụng một bản tin APDU thích hợp.

điều 11.3.3.3

18

Máy chủ xác nhận yêu cầu từ bước 17 và gửi AKH đến CICAM bằng cách sử dụng một bản tin APDU thích hợp.

điều 11.3.3.3

19

CICAM phải kiểm tra xem AKH nhận được tmáy chủ có giống AKM được CICAM tính. Việc không giống nhau sẽ dẫn đến giao thức xác thực không thành công (CHÚ THÍCH 3).

 

Ghi chú:

1: Tham chiếu phụ lục H để biết tng quan các thông số liên quan.

2: RSA được sử dụng để xác thực và kiểm tra SSAC như được trình bày trong phụ lục I. Các trường dữ liệu trong đóng du được nối bng cách sử dụng định dạng độ dài th được trình bày trong phụ lục J.

3: Hệ thống kiểm soát nội dung không thành công được quy định trong điều 6.1 và hình 6.1.

Tham chiếu đến điều 5.4.3 và phụ lục F đ biết thông tin chi tiết của cơ chế báo cáo lỗi chung.

6.2.3.1. Các thông số Diffie Helman

Các thông số Diffie Helman và yêu cầu của chúng không được định nghĩa trong tiêu chuẩn này và có th được tìm thy trong Đặc tvề giấy phép Cl Plus [33].

6.2.3.2. Tính các mã khóa công khai DH (DHPH và DHPM)

Các mã khóa công khai Diffie Helman (DHPH và DHPM) là không ổn định và phải bxóa sau khi hoàn thành giao thức xác thực.

Máy chủ phải tính toán mã khóa công khai Diffie Hellman của nó như sau:

DHPH=DH _public_KeyHost =gx mod p                                                        Eq.6.1

CICAM phải tính toán mã khóa công khai Diffie Hellman của nó như sau:

DHPM=DH_public_KeyModule = gy mod p                                                      Eq.6.2

Trong đó:

• Số mũ x (DHX) và số mũ y (DHY) là ngẫu nhiên và được một PRNG tạo ra theo quy định tại Phụ lục A. Các số mũ DHX và DHY phải được giữ bí mật và địa phương và phải bị xóa sau khi hoàn thành giao thức xác thực. Giá trị của g và p được quy định trong Đặc tả về giấy phép Cl Plus [33]. Sau khi tính toán của một mã khóa công khai DH, phải thực hiện các kim tra sau đây:

• kiểm tra xem 1 < DH_ public_key < DH_p ʌ DH_ public_keyDH-q mod DH_p = 1.

Chú ý: tham khảo Phụ lục H để biết tng quan về các thông số liên quan.

6.2.3.3. Tính các mã khóa DH (DHSK)

Mã khóa mật Diffie Helman (DHSK) phải được lưu trữ trong bộ nhớ ổn định. Mã khóa này phải được tính như sau:

DHSK = DH_private_KeyHost = (DHPM)x mod DH_p = (DHPH)y mod DH_p = DH_ private _KeyModule Eq.6.3

6.2.3.4. Tính mã khóa xác thực (AKH và AKM)

Mã khóa xác thực AKH/AKM phải được sử dụng để tính toán mã khóa SAC (xem điều 7.1.3) và mã khóa kiểm soát nội dung (CCK) (xem điều 8.1.4). Việc tạo mã khóa xác thực chỉ xảy ra một lần (mỗi cặp máy chủ- CICAM) khi CICAM và máy chủ được kết nối lần đầu. Các mã khóa xác thực thu được (AKM dành cho CICAM và AKH dành cho máy chủ) phải được lưu trữ trong bộ nhớ ổn định. Các mã khóa này phải được tính như sau:

AKM ≡ AKH = SHA256 (CICAM_ID ǁ Host_ID ǁ DHSK )                                Eq.6.4

Các thông số đầu vào phải tuân theo Bảng 6.4.

Bảng 6.4 - Các thông số đầu vào trong tính toán mã khóa

Mã khóa hoặc biến số

Kích thước (bit)

Diễn gii

Tham chiếu đến

DHSK

2048

Mã khóa mật DH đầy đ từ quá trình xác thực.

điều 6.2.3.3

HOST_ID

64

Được ROT tạo ra và được bao gồm trong giấy chứng nhận X.509 của máy chủ.

điều 9.3.6

CICAM_ID

64

Được ROT tạo ra và được bao gồm trong giấy chứng nhận X.509 của CICAM.

điều 9.3.6

CHÚ THÍCH:

1. Đầu vào được gắn tùy theo SHA-256. Tham chiếu FIPS 180-3 [3]. Việc thực hiện SHA nên tuân theo danh sách hợp lệ SHS. Xem danh sách hợp lệ SHS [11].

2. Tham chiếu phụ lục H để biết tổng quan các thông số liên quan.

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

Sau khi thiết lập phiên CC, CICAM và máy chủ thực hiện giao thức kiểm tra mã khóa xác thực để kiểm tra xem có tồn tại liên kết giữa hai thiết bị này và việc xác thực lại là không cần thiết.

Các trường hợp xác thực có chứa dữ liệu được yêu cầu để kiểm tra mã khóa xác thực và khởi tạo với xác thực chưa đầy đủ, bao gồm:

• AKM/AKH

• DHSK

• CICAM ID/máy chủ ID

• ID thương hiệu của CICAM được sử dụng để ngăn chặn dịch vụ của máy chủ

• Thuật toán xáo trộn được thương lượng trong quá trình liên kết này

Máy chủ phải lưu trữ 5 trường hợp xác thực này. CICAM phải hỗ trợ ít nhất một trường hợp xác thực và có th hỗ trợ nhiều trường hợp xác thực khác.

Nếu CICAM có một trường hợp xác thực hợp lệ, nó yêu cầu AKH từ máy chủ và kiểm tra xem AKH nhận được có phù hợp với AKM trong trường hợp xác thực của nó. Nếu không phù hợp, CICAM phải cố thử cho đến khi phù hợp hoặc đã được thực hiện tối đa 5 ln th. Máy chủ trải qua trường hợp xác thực của nó và gửi lại các AKH tương ứng. Khi có phù hợp, xác thực nhanh được hoàn thành và máy chủ và CICAM tiếp tục với việc thiết lập SAC. Khi máy chủ không có một trường hợp xác thực hợp lệ, nó trả lời với giá trị AKH có tất cả các slà không. Khi nhận được AKH không hợp lệ này CICAM dừng việc cố thử và bắt đầu giao thức xác thực.

Việc thực hiện trên CICAM và máy chủ nên cố gắng giảm thiểu tối đa các trường hợp này khi có yêu cầu xác thực đầy đủ.

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

Cl SAC mã hóa và gii mã dữ liệu như các APDU thành các bản tin SAC. Một biểu đồ cp cao theo ngữ cảnh được thể hiện trong hình 7.1:

CHÚ THÍCH: Cl SAC có thể gửi và nhận các bản tin cả hai chiều.

Hình 7.1 - Tng quan theo ngữ cảnh của CI SAC

Hình 7.2 được cung cấp để tham khảo:

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

Hình 7.2 - Biểu đồ trình tự Cl SAC

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

Bảng 7.1 - Tổng quan theo ngữ cảnh của Cl SAC

TT

Mô tả

Tham chiếu đến

1

Giao thức xác thực.

điều 6.2

2

CICAM và máy chủ phải hoàn thành thành công giao thức xác thực tương hỗ này.

 

3

Khi tạo SAC.

điều 7.1.1

..

6

SAC phải được khi tạo trên CICAM và máy chủ. Điều này liên quan đến việc lấy thông tin mã khóa và thiết lập (lại) trạng thái SAC ban đầu.

 

7

Yêu cầu đồng bộ SAC và xác nhận đồng bộ SAC.

điều 7.1.1

8

Nếu CICAM đã khởi tạo đúng Cl SAC, CICAM phải gửi một APDU để đồng bộ với máy chủ. Sau khi xác nhận thành công, cả hai phía có thể bắt đầu sử dụng SAC này.

 

9

Tạo và truyền bản tin SAC.

điều 7.3

..

15

Bản tin SAC được tạo ra dành cho tải bằng cách thêm phần mào đầu bản tin,

 

16

...

21

Nhận và kiểm tra bản tin SAC.

Khi nhận được bản tin SAC, nó phải được kiểm tra và nếu hợp lệ, tải của nó có thể được xử lý tiếp.

điều 7.4

CHÚ THÍCH:

1. Cl SAC có thgửi và nhận các bản tin cả hai chiều.

2. Tham chiếu đến điều 7.5 để biết cách SAC được ghép trong kiến trúc Cl Plus.

3. Tham chiếu các bng 11.28 và 11.30 để biết tổng quan các bn tin được trao đổi qua SAC.

7.1. Hoạt động Cl SAC

7.1.1. Khởi tạo SAC

Phần này quy định chi tiết về cách khởi tạo SAC. Hình 7.3 được cung cấp để tham khảo:

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

Hình 7.3 - Biu đồ trình tự tính toán mã khóa SAC

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

Bảng 7.2 - Tính toán mã khóa SAC

TT

Mô tả

Tham chiếu đến

1

Khi CICAM phát hiện thấy có yêu cầu mã khóa (lại) SAC, CICAM phải bắt đầu quá trình khởi tạo SAC. Các điều kiện chính xác để mã khóa (lại) được quy định trong điều tham chiếu ở cột bên.

điều 7.1.2

2

CICAM phải tạo nonce được sử dụng trong việc tính thông tin mã khóa SAC.

điều 7.1.3

3

CICAM phải gửi cc_data_req APDU đến máy chủ, bao gồm các thông số sau:

điều 11.3.3.5

 

• nonce Ns_module.

• CICAM_ID được lấy từ giấy chứng nhận thiết bị của CICAM.

 

4

Máy chủ phải tạo nonce được sử dụng trong việc tính thông tin mã khóa SAC

Điều 7.1.3

5

Máy chủ phải xác nhận đã nhận được cc_data_request APDU từ CICAM bằng cách gửi cc_data_cnf APDU đến CICAM, bao gồm các thông số sau:

• nonce Ns_Host.

• HOST_ID, được lấy từ giy chứng nhận thiết bị của máy chủ.

Không trả lời bằng cc_data_cnf dẫn đến hệ thống kiểm soát sao chép không thành công.

điều 11.3.3.5

6

CICAM phải kiểm tra xem HOST_ID nhận được có bằng HOST_ID được lưu trữ trước đó (xem CHÚ THÍCH 2). Nếu chúng giống nhau thì CICAM có thể bắt đầu tính SAK và SEK và thiết lập (lại) trạng thái SAC.

điều 7.1.3

7

Máy chủ phải kiểm tra xem CICAM_ID nhận được có bằng CICAM_ID được lưu trữ trước đó (xem CHÚ THÍCH 2). Nếu chúng giống nhau thì máy chủ có thể bắt đầu tính SAK và SEK và phải thiết lập (lại) trạng thái SAC.

điều 7.1.3

8

CICAM phải gửi cc_sync_req APDU đến máy chủ, chỉ ra SAK mới.

Khi CICAM đã khi tạo bộ xáo trộn, CICAM phải gửi yêu cầu đồng bộ đến máy chủ, chra rằng CICAM đã sẵn sàng bắt đầu sử dụng SAC này.

điều 11.3.3.5

9

Máy chủ phải xác nhận bằng a cc_sync_cnf APDU đến CICAM chra rằng nó đã sẵn sàng bắt đầu sử dụng SAC này.

Không trả lời bằng cc_sync_cnf dẫn đến hệ thống kiểm soát sao chép không thành công. Xem CHÚ THÍCH 3

điều 11.3.3.5

CHÚ THÍCH:

1. Tham chiếu phụ lục F để biết tổng quan các thông số liên quan trong giao thc này.

2. HOST_ID / CICAM_ID được lưu trữ trước đó trong 'Authentication Context'. Tham chiếu đến điều 6.3

3. Tham chiếu đến điều 5.4.3 và phụ lục F để biết thông tin chi tiết về cơ chế báo cáo lỗi chung.

7.1.2. Các điều kiện mã khóa (lại) SAC

Việc làm mới mã khóa SAC được CICAM khi tạo, trong khi máy chủ trả lời một cách thụ động. Việc làm mới mã khóa SAC phải được kích hoạt dưới một trong các điều kiện sau:

• Khi khởi động lại; khi khởi động (lại) được hoàn thành thành công và có một AKM hợp lệ được lưu trữ trong bộ nhớ.

• Khi ghép (lại) một CICAM; khi một CICAM được ghép lại vào một máy chủ và có một AKM hợp lệ được lưu trữ trong bộ nhớ.

• Khi xác thực (lại); khi không có AKM hợp lệ được lưu trữ trong bộ nhớ, phiên xác thực này được khởi tạo (lại), dẫn đến việc hoàn thành thành công (tức là AKM hợp lệ) của phiên xác thực (lại) tiếp theo.

• Khi bộ đếm bản tin quá tải.

Hình 7.4 giải thích hoạt động CICAM dành cho việc làm mới mã khóa SAC.

CHÚ THÍCH: Giới hạn số lần cố thử là 3 và được áp dụng đối với các lần không thành công tiếp theo của giao thức SAC trong bước 6.

Hình 7.4 - Lưu đồ - phiên làm mới mã khóa SAC của CICAM

Hình 7.5 giải thích hoạt động của máy chủ dành cho việc làm mới mã khóa SAC.

Hình 7.5 - Lưu đồ - phiên làm mới mã khóa SAC của máy chủ

7.1.3. Tính toán mã khóa SAC

SAC yêu cầu hai mã khóa để hoạt động: mã khóa xác thực SAC (SAK) và mã khóa mã hóa SAC (SEK). Việc tính toán SAK và SEK thực hiện theo hai bước:

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

• Đưa ra mã khóa SEK và SAK.

Các bước này được quy định như sau:

Bước 1: tính toán nhân mã khóa.

Nhân mã khóa Ks dài 256 bit và phải được sử dụng để tính toán mã khóa Km. Quá trình tính toán Ks phải được thực hiện trên máy chủ và CICAM.

Nhân mã khóa Ks phải được tính toán trên máy chủ như sau:

Kshost = SHA256 (DHSK ǁ AKH ǁ Ns_host ǁ Ns_module)                               Eq.7.1

Nhân mã khóa Ks phải được tính toán trên CICAM như sau:

KsCICAM = SHA256 (DHSK ǁ AKM ǁ Ns_host ǁ Ns_module)                            Eq.7.2

Trong đó:

Ks CICAM = Ks host

• Các thông số đầu vào được quy định tại Bảng 7.3:

Bảng 7.3 - Các thông số đầu vào trong tính toán mã khóa

Mã khóa hoặc biến số

Kích thước (bit)

Diễn giải

Tham chiếu đến

DHSK

128

Các bit LSB của mã khóa mật DH từ quá trình xác thực. Xem CHÚ THÍCH 3

điều 6.2.3.3

AKH/AKM

256

Các mã khóa xác thực từ quá trình xác thực.

điều 6.2.3.4

Ns_Host

64

Nonce 64 bit ngẫu nhiên được máy chủ tạo và được máy chủ truyền đến CICAM.

Phụ lục A

Ns_module

64

Nonce 64 bit ngẫu nhiên được CICAM tạo và được CICAM truyền đến máy chủ.

Phụ lục A

CHÚ THÍCH:

1. Đầu váo được gắn tùy theo SHA-256. Tham chiếu FIPS 180-3 [3]. Việc thực hiện SHA nên tuân theo danh sách hợp l SHS. Xem danh sách hợp lệ SHS [11].

2. Các yêu cầu đối với bộ tạo số ngẫu nhiên của Ns_Host và Ns_module được trình bày trong phụ lục A

3. DHSK bị ct từ 1024 xuống 128 bit

Bước 2: tính toán mã khóa.

Mã khóa Km dài 256 bit và phải được sử dụng để đưa ra SEK và SAK. Mã khóa Km phải được tính như sau:

SEK,SAK = f-SAC(Ks)                                                                             Eq.7.3

Lưu ý: Hàm f-SAC không được định nghĩa trong tiêu chuẩn này và được lấy từ Đặc tả về giấy phép Cl Plus [33].

7.1.4. Các mã lỗi SAC và thiết lập (lại) trạng thái SAC

Các điều kiện mã khóa lại SAC được giải thích trong Hình 7.6.

Hình 7.6 - Xử lý trạng thái SAC.

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

Một bản tin dữ liệu được truyền tải cho Cl SAC phải được chuyển đổi thành một bản tin SAC như sau:

CHÚ THÍCH: SAC được xác thực trước tiên và sau đó được mã hóa.

Hình 7.7 - Thành phần bản tin SAC

Cú pháp bản tin SAC chi tiết được định nghĩa trong Bảng 7.4.

Bảng 7.4 - Cú pháp bản tin SAC

Trường

Số bit

Kiểu

message() {

 

 

message_counter

    /* Mào đầu bản tin bắt đầu đây */

32

uimsbf

    protocol_version

4

uimsbf

    authentication_cipher_flag

3

uimsbf

    payload_encryption_flag

1

bslbf

    encryption_cipher_flag

3

uimsbf

    reserved for future use

5

bslbf

    length_payload

    /* Mào đầu bản tin kết thúc đây */

    /* Phần thân bản tin bắt đầu đây */

16

uimsbf

    if (payload_encryption_flag == MSG_FLAG_TRUE) {

 

 

    encrypted_payload

    } else if (payload_encryption_flag == MSG_FLAG_FALSE) {

length_payload *8 + 128

bslbf

    payload

length_payload * 8

bslbfk

    authentication

    }

    /* Phần thân bản tin kết thúc đây */

}

128

bslbf

7.2.1. Các hằng số

Bản tin này quy định các hằng số được định nghĩa trong Bảng 7.5.

Bảng 7.5 - Các hằng số trong bn tin SAC

Tên

Giá trị

MSG_FLAG_FALSE

0

MSG_FLAG_TRUE

1

7.2.2. Mã hóa và ngữ nghĩa của các trưng

message_counter: Một bản tin dữ liệu yêu cầu một bộ đếm duy nhất. Việc sử dụng trường này được giải thích trong điều 7.4.1.

protocol_version: tham số này chỉ ra phiên bản giao thức của bản tin này. Thiết bị này phải bqua bản tin có số của protocol_version mà nó không hỗ trợ. Trong tiêu chuẩn này, giá trị của protocol_version của bản tin này phải được thiết lập là 0x0.

authentication_cipher_flag: Tham số này là chỉ ra thuật toán giải mã hóa được sử dụng để tạo ra trường xác thực này theo quy định tại Bảng 7.6:

Bảng 7.6 - Các giá trị cho phép đối với authentication_cipher_flag

Nội dung

Ý nghĩa

Diễn giải

0x0

AES-128-XCBC-MAC

Chế độ XCBC-MAC được trình bày trong RFC 3566 [20] (CHÚ THÍCH 2)

0x1-0x7

Dự phòng

 

CHÚ THÍCH

1. Thiết bị tuân theo tiêu chun này phải phân tích giá trị 0x0 và bỏ qua các bản tin có giá trị authentication_cipher_flag không được hỗ trợ.

2. Ngoi trừ đầu ra MAC 128 bit MAC không bị cắt và giữ nguyên 128 bit.

payload_encryption_flag: tham số này chỉ ra nếu tải được mã hóa. Giá trị 1 chỉ ra mã hóa tải và giá trị 0 chỉ ra không mã hóa tải. Một thiết bị tuân theo tiêu chuẩn này phải phân tích giá trị là 1 và b qua các bản tin có giá trị payload_encryption_flag không được hỗ trợ khác.

encryption_cipher_flag: tham số này chỉ ra thuật toán giải mã hóa được sử dụng để mã hóa tải của bản tin như quy định tại Bảng 7.7:

length_payload: Thông số này là độ dài bản tin của ti tính theo byte bao gồm cả phần đệm tùy chọn, không bao gồm độ dài xác thực đối với cả tải được mã hóa và không được mã hóa.

encrypted_payload: trường này chứa dữ liệu được mã hóa bao gồm tải của bản tin, phần đệm nếu được yêu cầu và xác thực. Tham khảo điều 7.3.2 dành cho mô tcủa trường này.

payload: trường này mang tải của bn tin không được mã hóa (ví dụ dữ liệu đầu vào như một APDU).

authentication: trường này mang xác thực của bản tin. Tham khảo điều 7.3.1 dành cho mô tả về thủ tục xác thực. Trường này có thể được mã hóa và thông báo bằng "payload_encryption_flag"; tham khảo điều 7.3.2 để biết chi tiết.

CHÚ THÍCH: Cl SAC có th gửi và nhận các bản tin cả hai chiều

Hình 7.8 - Nhiều Mô-đun

Bảng 7.7 - Các giá trị cho phép đối với encryption_cipher_fIag

Nội dung

Ý nghĩa

Diễn giải

0x0

AES-128 in CBC mode

AES-128 tuân theo FIPS 197 [4] trong chế độ CBC tuân theo 800-38A [25]

0x1-0x7

Dự phòng

 

CHÚ THÍCH: Thiết bị tuân theo tiêu chun này phải phân tích giá tr0x0 và b qua các bản tin có giá trauthentication_cipher_flag không được hỗ trợ.

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

Một bản tin dữ liệu được gửi đến Cl SAC phải được xử lý như sau:

1) Kiểm tra message_counter xem đã bị dùng hết và cập nhật message_counter. Tham khảo điều 7.2.2 để biết chi tiết.

2) Tính toán xác thực của bản tin. Tham khảo điều 7.3.1 để biết chi tiết.

3) Ghép xác thực và tải và (tùy chọn) mã hóa bản tin này. Tham khảo điều 7.3.2 để biết chi tiết.

4) Dựng lên bản tin cuối cùng: (message_counter ǁ phần mào đầu I phần bản tin thu được từ bước 3). Tham khảo điều 7.2 để biết chi tiết.

5) Truyền bản tin này.

Chú ý: Nếu một trong các bước này thất bại, bản tin và trạng thái này (ví dụ như cặp mã khóa, bộ đếm, v.v..) phải bị hủy và một lỗi phi được đưa ra. Tham khảo điều 7.1.4 để biết chi tiết.

7.3.1. Xác thực bản tin

Bản tin dữ liệu trên Cl SAC được một trường xác thực bảo vệ. Trường xác thực này được tính như sau:

authentication = MAC {SAK}(length(header_hi)iheader _hipayload_Pi)   Eq.7.4

Trong đó:

• MAC là thuật toán được authentication_cipher_flag quy định, xem điều 7.2.2.

• SAK một khóa 128 bit, theo quy định tại điều 7.1.3.

• Việc xác thực được thực hiện trên toàn bộ bản tin, ngoại trừ trường xác thực. Các thông số này được sử dụng trong tính toán trường xác thực được quy định trong Bảng 7.8:

Bảng 7.8 - Các thông số trong tính toán của MAC

Thông số

Độ dài

Kiểu

length_hi

8

uimsbf

i

32

uimsbf

header_hi

length_hi * 8

bslbf

payload_pi

y * 8

bslbf

i - Trường này chứa giá trmessage_counter từ bn tin này. Tham khảo điều 7.2.2 dành cho mô tả của trường này.

Iength_hi - Thông số này là độ dài của phần mào đầu tính theo byte.

header_hi - Thông số này trình bày phần mào đầu của bản tin, xem Bảng 7.4:

payload_pi - Thông số này chứa tải của bản tin. Đ tính toán trường xác thực này, tải không được mã hóa ban đầu phải được sử dụng.

7.3.2. Mã hóa bản tin

Một cờ cho biết nếu tải được mã hóa hay không. Nếu một bản tin SAC yêu cầu mã hóa, dữ liệu này được mã hóa như sau:

encryted _ payloadi = E{SEK,SIV}(payload_pi authentication _ai)              Eq.7.5

Trong đó:

• E là thuật toán được encryption_cipher_flag quy định, xem điều 7.2.2.

• SEK là mã khóa 128 bit. Tham khảo điều 7.1.3 để biết chi tiết.

• SIV là cố định, dài 128 bit và một hằng số của giấy phép, tham khảo Đặc tả về giấy phép Cl Plus [33]. SIV phải được sử dụng ở phn đầu của mỗi bản tin SAC.

• Xác thực ai phải được tính như mô tả trong điều 7.3.1.

Chú ý: Nếu payload_pi không là bội số của kích thước khối mã (tức là 128 bit) thì bản tin này được đệm bng cách thêm bit 1 (một) và tiếp theo là bit 0 (không) cho đến khi kích thước khối được làm đy. Nếu tải không được mã hóa thì việc đệm không được áp dụng.

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

Một bản tin dữ liệu được Cl SAC nhận phải được xử lý như sau:

1) Trước tiên kiểm tra xem bản tin nhận được có chứa message_counter và protocol_version chính xác. Tham khảo điều 7.4.1 để biết chi tiết.

2) Nếu payload_encryption_flag = 1 thì giải mã tải của bản tin được mã hóa. Tham khảo điều 7.4.2 để biết chi tiết chính xác.

3) Tính toán lại trường xác thực và kiểm tra tính toàn vẹn của bản tin. Tham khảo điều 7.4.3 để biết chi tiết.

Chú ý: Nếu một trong các bước này tht bại thì bản tin và trạng thái (ví dụ như cặp mã khóa, bộ đếm, v.v..) phải bị hủy và một lỗi phải được đưa ra. Tham khảo điều 7.1.4 để biết chi tiết.

7.4.1. Trạng thái bộ đếm bản tin

Thiết bị nhận (CICAM hoặc máy chủ) phải duy trì nội bộ một bộ đếm bản tin an toàn dành cho các bản tin nhận được để theo dõi số bản tin của bản tin cuối cùng nhận được. Khi nhận được một bản tin từ Cl SAC, máy chủ phải cập nhật trạng thái của receiver_message_counter. receiver_message_counter là một trường 32 bit (là trường bộ đếm bản tin của bn tin này).

Bất kỳ số bản tin mới phải có số bản tin được tăng một cách chặt chẽ i. Bn tin đầu tiên phải sử dụng số 0x1, thứ hai tương ứng số 0x2, và tiếp tục như vậy. Phía nhận không được nhận các bản tin không có thứ tự này.

Số bản tin chính xác: (i = receiver_message_counter + 1)

Số bản tin không chính xác: (ireceiver_message_counter) ˅ (i > receiver_message_counter+1)

S bản tin không chính xác gây ra "lỗi thứ tự bn tin"; Điều này phải được xử lý như đã giải thích trong điều 7.1.4

Các giới hạn của bản tin:

Sbn tin bị giới hạn 2 32-1 bản tin. Trường hợp số bản tin vượt quá, thiết bị phải dừng sử dụng các mã khóa hiện tại và thương lượng các mã khóa mới (xem điều 7.1.2). Số bản tin, i, trở lại 0x1 (khác không).

Chú ý: CICAM là thiết bị duy nht có thể quyết định và khi tạo các hành động tiếp theo dựa vào việc sử dụng hết của bộ đếm bản tin. Hành vi này được quy định tại điều 7.1.4.

7.4.2. Giải mã bản tin

Bản tin dữ liệu trên Cl SAC có thể được mã hóa. Việc giải mã được thực hiện như sau:

payload _ p, □ authentication _ ai = D{SEK, SIV}(encrypted_payloadi)         Eq.7.6

Trong đó:

• D là thuật toán được encryption_cipher_fIag quy định, xem điều 7.2.2.

• SEK là mã khóa 128 bit. Tham khảo điều 7.1.3 để biết chi tiết.

• SIV là cố định, dài 128 bit và một hằng số của giấy phép, tham khảo Đặc tả về giấy phép Cl Plus [33]. SIV phải được sử dụng phần đu của mỗi bản tin SAC.

• Việc giải mã một bản tin không chính xác gây ra một "lỗi giải mã bản tin"; Điều này được xử lý như trong điều 7.1.4

Chú ý: authentication_a i được tách ra từ payload_p i nơi độ dài của authentication_a i có thể được suy ra từ giá trị của authentication_cipher_flag.

Dữ liệu đầu vào SAC ban đầu = payload_pi thu được - authentication_ ai.

Nếu payload_pi không là bội số của kích thước khối mã (tức là 128 bit) thì bản tin này được đệm bằng cách thêm bít 1 (một) và tiếp theo là bit 0 (không) cho đến khi kích thước khối được làm đầy. Nếu tải không được mã hóa thì việc đệm không được áp dụng.

7.4.3. Kiểm tra bản tin

Bản tin dữ liệu trên Cl SAC chứa một trường xác thực. Việc xác thực phải được xác nhận như:

authentication_a'i = MAC{SAK}(length(header_hi)□i□header_hi payload_pi)                    Eq.7.7

Trong đó:

• MAC là thuật toán được authentication_cipher_flag quy định, xem điều 7.2.2.

• SAK một khóa 128 bit, theo quy đnh tại điều 7.1.3.

• Để mô t các thông scòn lại tham khảo điều 7.3.1.

Chú ý: Nếu authentication_a i được tính không bằng authentication_a i được rút ra từ bản tin được giải mã (trong trường hợp payload_encryption_flag = 1), hoặc nếu a i được tính không bằng trường xác thực được chứa trong bn tin này (trong trường hợp payload_encryption_flag = 0) thì bản tin m nhận được phải bị loại bỏ và phải tạo ra một lỗi kiểm tra bản tin và xử lý như quy định tại điều 7.1.4.

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

SAC được thiết kế là một giao thức đa mục đích và được tích hợp vào tài nguyên CC như được giải thích trong hình 7.9.

Hình 7.9 -Tích hợp bản tin SAC

Bảng 7.9 - Đóng gói dữ liệu sang một bản tin SAC

TT

Mô t

Tham chiếu đến

1

Hệ thng thu thập các đối tượng dữ liệu tạo thành tải SAC.

điều 11.3.1.7

2

Hệ thống xác thực bn tin SAC đầy đủ, bao gồm phn mào đầu SAC, tải SAC và phần đệm (nếu yêu cầu).

điều 7.3

3

Tải SAC và xác thực SAC được mã hóa. Dữ liệu SAC được mã hóa được gắn với phần mào đầu SAC, thẻ APDU và độ dài APDU.

điều 7.5

CHÚ THÍCH: Tham chiếu Bng 11.10 dành cho các bản tin được truyn qua SAC

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

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

Hình 8.1 được sử dụng để tham khảo:

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

Hình 8.1 - đồ trình tự tính toán CCK.

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

Bảng 8.1 - Tính toán CCK

TT

Mô t

Tham chiếu đến

1

Khi CICAM phát hiện có yêu cầu làm mới CCK, CICAM phi bắt đầu quá trình khi tạo CCK. Các điều kiện chính xác để mã khóa (lại) được quy định trong điều tham chiếu cột bên.

điều 8.1.2

2

CICAM tạo nonce để tạo Kp như sau:

Kp = SHA256 (nonce)

Phụ lục A.1

3

CICAM có thể ngay lập tức bắt đầu tính CIV và/ hoặc CCK.

điều 8.1.4

4

CICAM phải gửi cc_sac_data_req APDU đến máy chủ, bao gồm các thông số sau:

• Kp.

• CICAM_ID được lấy từ giấy chứng nhận thiết bị của CICAM.

• Lựa chọn thanh ghi chẵn hoc lẻ.

điều 11.3.3.4

5

Máy chủ phải kiểm tra xem CICAM_ID nhận được có giống CICAM_ID được lưu trữ trước đó (Xem CHÚ THÍCH 5). Nếu chúng giống nhau, máy chủ có thể bắt đầu tính CIV và/ hoặc CCK.

Việc kiểm tra CICAM_ID không thành công phải dẫn đến trả lời 'no CC support'.

điều 8.1.4

6

Máy chủ phi xác nhận bằng cc_sac_data_cnf APDU đến CICAM, bao gồm các thông số sau:

• HOST_ID được lấy từ giấy chứng nhận thiết bị của máy chủ.

Không trả lời bằng cc_data_cnf dẫn đến hệ thống kiểm soát sao chép không thành công.

điều 11.3.3.4

7

CICAM phải kiểm tra xem HOST_ID nhận được có giống HOST_ID được lưu trữ trước đó (CHÚ THÍCH 5). Nếu chúng giống nhau, CICAM có thể sử dụng CCK và CIV đã được tính.

Việc máy chủ trả li 'CC_no support' hoặc việc kiểm tra HOST_ID không thành công dẫn đến hệ thống kiểm soát sao chép không thành công. Xem CHÚ THÍCH 6

điều 8.1.4

8

Máy chủ có thể tính CIV và/ hoặc CCK.

điều 8.1.4

9

CICAM phải gửi cc_sac_sync_req APDU đến máy chủ, chỉ ra CCK mới.

Khi CICAM đã hoàn thành việc khởi tạo bộ xáo trộn, CICAM phải gửi yêu cầu đồng bộ đến máy chủ. Điều này thông báo cho máy chủ rằng CICAM đã sẵn sàng để bắt đầu sử dụng CCK mới được tính.

điều 11.3.3.4

10

Máy chủ phải gửi cc_sac_sync_cnf APDU đ xác nhận với CICAM rằng nó đã sẵn sàng để bắt đu sử dụng CCK mới được tính.

Việc không trả lời bằng cc_sac_sync_cnf dẫn đến hệ thống kiểm soát sao chép không thành công. Xem CHÚ THÍCH 6.

điều 11.3.3.4

CHÚ THÍCH:

1. Khi đã được tính, thông tin mã khóa mới phải được lưu trữ trong một thanh ghi thích hợp của bộ (giải) xáo trộn. Tham chiếu đến điều 5.6 để biết thông tin chi tiết.

2. Các điều kiện làm mới CCK được quy định trong điều 8.1.2.

3. Tham chiếu Phụ lục H để biết tổng quan các thông số liên quan.

4. Các APDU này được yêu cu trong giao thức làm mới CCK phải được gửi qua SAC; tham chiếu đến điều 7.

5. HOST_ID / CICAM_ID được lưu trữ trước đó trong 'Authentication Context'. Tham chiếu đến điều 6.3

6. Tham chiếu đến điều 5.4.3 và phụ lục F để biết thông tin chi tiết về cơ chế báo cáo lỗi chung.

8.1.2. Các điều kiện mã khóa lại mã khóa kiểm soát nội dung

Việc làm mới mã khóa kiểm soát nội dung (CCK) được CICAM khi tạo, trong khi máy chủ trả lời một cách thụ động. Việc làm mới CCK phải được kích hoạt dưới một trong các điều kiện sau:

• Sau khi cả hai quá trình khi tạo SAC và xác thực đã hoàn thành thành công.

• Khi được CAS kích hoạt.

• Khi được kích hoạt định kỳ (tham số thời gian sống lớn nhất của mã khóa). Xem điều 8.1.3.

• Khi giới hạn bộ đếm khối bị tràn (chỉ dành cho chế độ AES).

• Tại mỗi khi khi động lại.

• Tại mỗi khi thiết lập lại CICAM.

Hình 8.2 giải thích hoạt động của CICAM khi làm mới CCK.

CHÚ THÍCH:

1. Đồng hồ làm mới mã khóa là thời gian chờ để tính CCK mới; Tham khảo hình 5.15 để biết thông tin chi tiết

2. Thời gian sống của mã khóa được trình bày trong điều 8.1.3

3. Giới hạn bộ đếm khối được quy định trong bảng 8.2

4. Key_lifetime ban đầu được quy định là khoảng thời gian sống của mã khóa đu tiên (tức là khong thời gian tính CCK) sau khi khởi tạo (lại) SAC.

5. Việc bắt đầu hoạt động xáo trộn CC phụ thuộc vào dữ liệu URI liên kết với dịch vụ được chọn

Hình 8.2 - Hoạt động của CICAM khi làm mới CCK

Bảng 8.2 - Các giới hạn của bộ đếm khối của bộ xáo trộn

Lựa chọn bộ xáo trộn

Giới hạn của bộ đếm khối

Diễn giải

DES

Không áp dụng

không được sử dụng

AES

232

 

CHÚ THÍCH: Giới hạn của bộ đếm khối là s khối mã đã được xử lý từ khi làm mới CCK.

Hình 8.3 giải thích hoạt động của máy chủ khi làm mới CCK.

Hình 8.3 - Hoạt động của máy chủ khi làm mới CCK

8.1.3. Thời gian sống của mã khóa nội dung

Tham số thời gian sống lớn nhất của mã khóa được hệ thống CA kiểm soát và nằm ngoài phạm vi của tiêu chun này. Việc đếm ngược giá trị này được CICAM duy trì để kích hoạt quá trình làm mới CCK.

Việc đếm ngược chđược thực hiện khi CICAM đang xáo trộn nội dung. Điều này đảm bảo rằng không tính toán lại mã khóa nội dung khi không đang sử dụng nó.

8.1.4. Tính toán mã khóa kim soát nội dung (CCK)

Bộ xáo trộn yêu cầu một mã khóa nội dung (và IV nếu được yêu cầu) dành cho hoạt động của nó: mã khóa kiểm soát nội dung (CCK) và véc-tơ khởi tạo nội dung (CIV). Việc tính toán CCK (và CIV) được thực hiện theo hai bước:

• Tính tiền thân của mã khóa

• Rút ra mã khóa CCK và CIV.

Các bước này được quy đnh như sau:

Bước 1: tính tiền thân của mã khóa.

Tiền thân của mã khóa Kp dài 256 bit và phải được sử dụng để tính Km. Quá trình tính Kp phải được thực hiện trên CICAM.

Tiền thân của mã khóa Kp được tính trên CICAM như sau:

K p = S H A 256 (n o n ce)                                                                          Eq.8.1

Trong đó:

• Các thông số đầu vào được quy định tại Bảng 8.3:

Bảng 8.3 - Các thông s đầu vào trong việc tính mã khóa

Mã khóa hoặc biến số

Kích thước (bit)

Diễn giải

Tham chiếu đến

nonce

256

Nonce 256 bit ngẫu nhiên được CICAM tạo ra.

Phụ lục A

CHÚ THÍCH:

1. Đầu vào được gắn tùy theo SHA-256. Tham chiếu FIPS 180-3 [3]. Việc thực hiện SHA nên tuân theo danh sách hợp lệ SHS. Xem danh sách hợp lệ SHS [11].

2. Các yêu cầu đối với bộ tạo số ngẫu nhiên của nonce được trình bày trong phụ lục A

Bước 2: tính toán mã khóa.

Mã khóa Km dài 256 bit và được sử dụng đrút ra mã khóa kiểm soát nội dung (CCK). Mã khóa Km được tính như sau:

CCK,CIV = f - CC (Kp)                                                                             Eq.8.2

Lưu ý: hàm f - CC không được định nghĩa trong tiêu chun này và có thể tham khảo Đặc tả về giấy phép Cl Plus [33].

Sau khi xác thực thành công, hệ thống sẽ xác định xem các thuật toán giả mã hóa AES hay DES có được sử dụng để bảo vệ nội dung chưa được CA xáo trộn trả lại máy chủ (xem điều 6). Mã kiểm soát nội dung (CCK) và véc-tơ khởi tạo (CIV) được rút ra từ mã khóa Km theo những cách khác nhau dành cho bộ xáo trộn AES-128 và bộ xáo trộn DES-56.

8.1.5. Mã khóa nội dung dành cho bộ xáo trộn DES-56-ECB.

Mã khóa nội dung DES-56 (CCKDES) là 64 bit. Mã khóa CCK từ f-CC được đệm với các bit chẵn lẻ theo cách giống như SCTE41 [5], Phụ lục B sang CCKDES thu được. CCKDES phải được thay đổi như được quy định tại điều 5.6.1.

Khi sử dụng DES, phải sử dụng CCK để giải xáo trộn gói tin TS như sau:

clear _ packet = DDES-56-ECB{CCKDES}(Ts_Packet)                                          Eq.8.3

Chú ý: Tham khảo điều 5.6.2.2 dành cho các đặc điểm chi tiết của bộ xáo trộn (lại) DES.

8.1.6. Mã khóa nội dung và IV dành cho bộ xáo trộn AES-128-CBC

Mã khóa nội dung AES-128 (CCKAES) có chiều dài 128 bit. Khi sử dụng AES, phải áp dụng CCK và CIV vào AES để giải xáo trộn gói tin TS như sau:

clear _ packet = DDES-128-CBC {CCKAES}{CIV}(Ts_Packet)                                 Eq.8.4

Trong đó:

• CCKAES phải thay đổi theo quy định tại điều 5.6.1. Ngoài ra, CCK AES phải được thay đổi sau khi xử lý 2 32 khối AES.

• CIV là cố định đối với mỗi giai đoạn thời gian sống của mã khóa và phải thay đổi khi CCK thay đổi. CIV hiện tại phải được sử dụng lại phn đầu của mỗi gói tin MPEG2 TS.

Chú ý: Tham khảo điều 5.6.2.3 dành cho đặc điểm chi tiết của bộ xáo trộn (lại) AES.

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

9.1. Giới thiệu

Việc xác thực giữa một máy chủ Cl Plus và mô-đun bao gồm việc trao đổi chứng nhận. Chứng nhận thiết bị của một máy chủ hoặc mô-đun phục vụ 3 mục đích:

• Chứng minh rằng thiết bị tuân thủ Bản quy định kỹ thuật Cl Plus

• Cung cấp một mã khóa công khai RSA của thiết bị. Mã khóa này được sử dụng để kiểm tra mã khóa công khai Diffie- Hellman của thiết bị trong giao thức xác thực, xem hình 6.2 và Bảng 6.1

• Truyền những khả năng bộ xáo trộn của thiết bị

Mỗi nhà cung cấp dịch vụ cung cấp các dịch vụ Cl Plus có giy chứng nhận của nhà điều hành dịch vụ. Giấy chứng nhận này được CICAM sử dụng đkiểm tra tính toàn vẹn của danh sách thu hồi mà nó nhận được.

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

Hệ thống phân cấp tin cậy Cl Plus được tổ chức theo cấu trúc hình cây với một gốc tin cậy duy nhất (ROT). Chỉ có một cây dành cho tt cả các thành viên tham gia Cl Plus, xem Hình 9.1.

Hình 9.1- Cây phân cấp giấy chứng nhận

Có bốn loại giấy chứng nhận khác nhau.

• Giấy chứng nhận gốc

- do ROT cấp

- tự đóng dấu

- chỉ có một giy chứng nhận gốc tồn tại dành cho tất cả các thiết bị Cl Plus

• Giấy chứng nhận thương hiệu

- do ROT cp

- đóng dấu với mã khóa riêng của giấy chứng nhận gốc

- một giấy chứng nhận của loại này tồn tại dành cho mỗi thương hiệu (hoặc nhà sản xuất)

• Giấy chứng nhận thiết bị

- do ROT cấp

- đóng dấu với mã khóa riêng của giấy chứng nhận thương hiệu

- mỗi thiết bị đơn lẻ có một giấy chứng nhận thiết bị duy nhất

• Giấy chứng nhận nhà điều hành dịch vụ

- do ROT cấp

- đóng dấu với mã khóa riêng của giấy chng nhận gốc

- một giấy chứng nhận của loại này tồn tại dành cho mỗi nhà điều hành dịch vụ

Mỗi giấy chứng nhận chứa một mã khóa công khai mà dành cho nó có một mã khóa riêng tương ứng.

Mỗi thiết bị máy chủ và mô-đun phải tích hợp các thông tin liên quan đến giấy chứng nhận sau tại thời điểm sản xut.

• Giấy chứng nhận gốc Cl Plus

• Giấy chứng nhận thương hiệu

• Giy chứng nhận thiết bị

• Mã khóa riêng tương ứng với giấy chứng nhận thiết bị (MDQ hoặc HDQ, xem Bng 5.2)

Giấy chứng nhận nhà điều hành dịch vụ có tính chất phát rộng và không giống như các giấy chứng nhận khác nên nó không được tích hợp vào máy chủ hoặc CICAM tại nơi sản xuất.

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

Tt cả các giấy chứng nhận Cl Plus phải được dựa vào hồ sơ Internet X.509, được quy định trong RFC 3280 [19]. Bản quy định kỹ thuật MHP 1.0.3, TS 101 812 [9], điều 12.11 cung cấp tổng quan về mã hóa giấy chứng nhận.

Định nghĩa ASN.1 của một giấy chứng nhận X.509 được ly từ RFC 3280 [19], điều 4.1, được trình bày dưới đây để tham khảo:

Certificate ::= SEQUENCE {

tbsCertificate TBSCertificate,

signatureAlgorithm Algorithmldentifier,

signatureValue BIT STRING}

TBSCertificate ::= SEQUENCE {

version [0] EXPLICIT Version DEFAULT v1,

serialNumber CertificateSerialNumber,

signature Algorithmldentifier,

issuer Name,

validity Validity,

subject Name,

subjectPublicKeylnfo SubjectPublicKeylnfo,

issuerUniquelD [1] IMPLICIT Uniqueldentifier OPTIONAL,

-- If present, version MUST be v2 or v3

subjectUniquelD[2] IMPLICIT Uniqueldentifier OPTIONAL,

-- If present, version MUST be v2 or v3

extensions [3] EXPLICIT Extensions OPTIONAL

-- If present, version MUST be v3

}

Version ::= INTEGER {v1(0), v2(1), v3(2)}

CertificateSerialNumber ::= INTEGER

Validity ::= SEQUENCE {

notBefore Time,

notAfter Time}

Time ::= CHOICE {

utcTime UTCTime,

generalTime GeneralizedTime}

Uniqueldentifier ::= BIT STRING

SubjectPublicKeylnfo ::= SEQUENCE {

algorithm AlgorithmIdentifier,

subjectPublicKey BIT STRING }

Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension

Extension ::= SEQUENCE {

extnID OBJECT IDENTIFIER,

critical BOOLEAN DEFAULT FALSE,

extnValue OCTET STRING }

Phần này giải thích các trường và các phần mrộng được sử dụng trong tiêu chuẩn này.

9.3.1. Phiên bản

Cl Plus phải sử dụng X.509 phiên bản 3.

9.3.2. Số sêri

Mỗi giấy chứng nhận phải bao gồm một số sêri duy nhất mà được tổ chức phát hành giấy chứng nhận cấp.

9.3.3. Đóng dấu

Tất cả các giấy chứng nhận sử dụng các đóng dấu RSASSA-PSS theo quy định tại PKCS1v2.1 [1], điều 8.1.1.

Bảng 9.1 - Thuật toán đóng dấu giấy chứng nhận

Thông số

Giá tr

hashAlgorithm

SHA-1

maskGenAlgorithm

MGF1 sử dụng SHA-1

saltLength

20 byte

trailerField

1 byte: 0xbc

Các nhãn định danh đối tượng ASN.1 tương ứng là

id-RSASSA-PSS OBJECT IDENTIFIER ::= { pkcs-1 10 }

pkcs-1 OBJECT IDENTIFIER ::= {

iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 1 }

rSASSA-PSS-Default-Params RSASSA-PSS-Params ::= {

sha1Identifier, mgf1SHA1Identifier, 20,1}

sha1Identifier AlgorithmIdentifier ::= { id-sha1, NULL }

id-sha1 OBJECT IDENTIFIER ::= {

iso(1) identified-organization(3) oiw(14) secsig(3) algorithms(2) 26 }

mgf1SHA1Identifier AlgorithmIdentifier ::= { id-mgf1, sha1Identifier }

9.3.4. Tổ chức phát hành

Các giấy chứng nhận Cl Plus (giống như tất cả các giấy chứng nhận X.509 khác) sử dụng một tên phân biệt X.501 [22] trong trường tổ chức phát hành. Bảng 9.2 ch ra trường tổ chức phát hành đối với các loại giấy chứng nhận khác nhau.

Bảng 9.2 - Tổ chức phát hành giấy chứng nhận

Loại giấy chứng nhận

Tổ chức phát hành

Giấy chứng nhận gốc

C: <quốc gia nơi ROT nm> ST: <bang/tnh nơi ROT nằm>

L: <thành phố nơi ROT nm>

O: <tên của ROT>

OU: <bộ phận của ROT chịu trách nhiệm đối với các giy chứng nhận Cl Plus>

OU: “đo th” hoặc “sản xuất”

CN: Giấy chứng nhận CA gốc Cl PLus

Giấy chứng nhận thương hiệu

C: <quốc gia nơi ROT nm> ST: <bang/tỉnh nơi ROT nằm> L: <thành phố nơi ROT nằm>

O: <tên của ROT>

OU: <bộ phận của ROT chu trách nhiệm đối với các giấy chứng nhận Cl Plus>

OU: “đo th” hoặc “sản xuất”

CN: Giấy chứng nhận CA gốc Cl PLus

Giy chứng nhận thiết bị

C: <quốc gia nơi thương hiệu nm> ST: <bang/ tỉnh nơi thương hiệu nằm> L: <thành phố nơi thương hiệu nm>

O: <tên của thương hiệu>

OU: “đo thử” hoặc “sản xuất”

CN: Cl Plus ROT for<tên của thương hiệu>

Giy chứng nhận nhà điều hành dịch vụ

C: <quốc gia nơi ROT nằm> ST: <bang/tỉnh nơi ROT nằm>

L: <thành phố nơi ROT nằm> O: <tên của ROT>

OU: <bộ phận của ROT chịu trách nhiệm đối với các giấy chứng nhận Cl Plus>

OU: “đo th” hoặc “sản xuất”

CN: Giấy chứng nhận CA gốc Cl PLus

Các thuộc tính X.501 được Cl Plus sử dụng là đt nước (C), bang (ST), khu vực (L), tên tổ chức (O), tên đơn vị (OU) và tên phổ biến (CN). Xin lưu ý rằng các thuộc tính tương tự có thể xuất hiện trong một tên nhiều lần.

Việc mã hóa ASN.1 của một tên phân biệt X.501 được định nghĩa trong RFC 3280 [19], điều 4.1.2.4. Tất cả các giá trị thuộc tính có th được mã hóa theo PrintableString hoặc UTF8String.

9.3.5. Hiệu lực

Hiệu lực của Giấy chứng nhận phải lớn hơn thời gian sống dự kiến của thiết bị. Tiêu chuẩn này không đưa ra phương pháp thay thế giy chứng nhận gốc, thương hiệu hoặc thiết bị. Giy chứng nhận nhà điều hành dịch vụ nhận được thông qua phát sóng và có thể dễ dàng được cập nhật; thời gian sống của nó có thể ngắn hơn đáng kể so với các giấy chứng nhận khác.

Định nghĩa của các thời gian sống chính xác dành cho các giấy chứng nhận này nằm ngoài phạm vi của tiêu chun này.

Thời gian trong các trường notBefore và notAfter phải được mã hóa theo Thời gian UTC và phải bao gồm giây, tức là có định dạng YYMMDDHHMMSSZ. Trường năm phải được hiểu là 20YY.

9.3.6. Đối tượng

Đối tượng là một tên phân biệt X.501 [22] và sử dụng mã hóa tương tự như trường tổ chức phát hành.

Bảng 9.3 - Đối tượng giấy chứng nhận

Loại giấy chứng nhận

Đối tượng

Giấy chứng nhận gốc

C: <quốc gia nơi ROT nm> ST: <bang/tỉnh nơi ROT nằm>

L: <thành phố nơi ROT nằm>

O: <tên của ROT>

OU: <bộ phận của ROT chịu trách nhiệm đối với các giấy chứng nhận Cl Plus>

OU: “đo th” hoặc “sản xuất”

CN: Giấy chứng nhận CA gốc Cl PLus

Giấy chng nhận thương hiệu

C: <quốc gia nơi thương hiệu nm> ST: <bang/ tnh nơi thương hiệu nm> L: <thành phố nơi thương hiệu nm>

0O: <tên của thương hiệu>

OU: “đo th” hoặc “sản xuất

CN: Cl Plus ROT dành cho” <tên thương hiệu>

Giy chứng nhận thiết bị

C: <quốc gia nơi thương hiệu nm> ST: <bang/ tỉnh nơi thương hiệu nằm>

L: <thành phố nơi thương hiệu nằm> O: <tên của thương hiệu>

OU: <tên sản phẩm> (tùy chọn) OU: “đo thử” hoặc “sản xuất

CN: <ID của thiết bị>

Giấy chứng nhận nhà điều hành dịch vụ

C: <quốc gia nơi nhà điều hành nm> ST: <bang/ tnh nơi nhà điều hành nằm> L: <thành phố nơi nhà điều hành nm>

O: <tên của nhà điều hành>

OU: “đo thử” hoặc “sản xuất

CN: <ID của nhà điều hành>

ID của thiết bị là một số thập lục phân gồm 16 số. Để lưu số này trong thuộc nh X.501 Common Name (CN), nó phải được chuyển đổi thành một chuỗi. Mỗi số được trình bày bằng mã ASCII tương ứng, tức là 1 được viết như 0x31 và 7 như 0x37. Đối với các số thập lục phân A đến F, các chữ hoa được sử dụng (giá trị các số thập lục là t 0x41 đến 0x46).

Để biết chi tiết về nội dung ID của thiết bị, tham khảo Đặc t về giấy phép Cl Plus [33].

ID của nhà điều hành dịch vụ là một số thập lục phân gồm 16 số. Nó được mã hóa giống như đối với ID của thiết bị. ID của nhà điều hành dịch vụ được sử dụng để liên kết một giấy chứng nhận nhà điều hành dịch vụ với tập tin dữ liệu thông báo thu hồi (RSD), xem điều 3.1.4 của Bản quy định kỹ thuật bổ sung Cl Plus [37].

9.3.7. subjectPublicKeylnfo

Thuật toán này là RSA sử dụng nhãn định danh đối tượng ASN.1

rsaEncryption OBJECT IDENTIFIER ::= { pkcs-1 1}

pkcs-1 OBJECT IDENTIFIER ::= {

iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 1 }

Trường các thông số phải có loại ASN.1 là NULL.

Số mũ công khai của mã khóa RSA phải là 65537 == 0x10001, độ dài mô đun phải là 2048 bit. Tham khảo RFC 3280 [19], điều 4.1.2.7 dành cho mã hóa khóa công khai.

9.3.8. issuerUniquelD và subjectUniquelD

Các thông số issuerUniquelD và subjectUniquelD được định nghĩa trong RFC 3280 [19], điều 4.1.2.8. Các giấy chứng nhận Cl Plus không được sử dụng các nhãn định danh duy nhất.

9.3.9. Phần m rộng

Các giấy chứng nhận dành cho Cl Plus sử dụng một số phần mở rộng tiêu chun này được định nghĩa trong RFC 3280 [19] và hai phần m rộng riêng dành cho Cl Plus. Bảng sau liệt kê các phần m rộng bắt buộc đối với từng loại giấy chứng nhận

Bng 9.4 -Các phần mở rộng giấy chứng nhận

Loại giy chứng nhận

Các phần mở rộng quy định

Giấy chứng nhận gốc

sử dụng mã khóa

nhãn nhận dạng mã khóa đối tượng

các giới hạn cơ bản

Giấy chứng nhận thương hiệu

sử dụng mã khóa

nhãn nhận dạng mã khóa đối tượng

nhãn nhận dạng mã khóa quyền các giới hạn cơ bản

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

sử dụng mã khóa

nhãn nhận dạng mã khóa quyền

các giới hạn cơ bản

scrambler capabilities

Thông tin Cl Plus (tùy chọn)

Nhãn nhận dạng thương hiệu CICAM (CICAM only)

Giấy chứng nhận nhà điều hành dịch vụ

sử dụng mã khóa

nhãn nhận dạng mã khóa quyền

các giới hạn cơ bản

Tt cả các phần m rộng khác có thể được sử dụng được định nghĩa trong RFC 3280 [19] và chúng không được xem là quan trọng. Máy chủ và CICAM tuân thCl Plus có thể b qua các phần m rộng này khi phân tích và kiểm tra giấy chứng nhận.

9.3.9.1. Nhãn định danh mã khóa đối tượng

Nhãn định danh mã khóa đối tượng phải được tính theo đề xuất (1) trong RFC 3280 [19], điều 4.2.1.2.

9.3.9.2. Nhãn định danh mã khóa cơ quan thẩm quyền

Phần mrộng nhãn định danh mã khóa cơ quan thẩm quyền được định nghĩa trong RFC 3280 [19], điều 4.2.1.1. Trường Keyldentifier phải được tính theo đề xuất (1) trong RFC 3280 [19], điều 4.2.1.2.

9.3.9.3. Sử dụng mã khóa

Phần mở rộng sử dụng mã khóa được định nghĩa trong RFC 3280 [19], điều 4.2.1.3 và phải luôn luôn sẵn có và được đánh dấu là quan trọng. Giá trị của KeyUsage phụ thuộc vào loại giấy chứng nhận như thể hiện trong Bảng 9.5.

Bảng 9.5 - Các giá trị sử dụng mã khóa dành cho các loại giấy chứng nhận

Loại giấy chứng nhận

Sử dụng mã khóa

Giấy chứng nhận gốc

keyCertSign crlSign

Giy chứng nhận thương hiệu

keyCertSign

Giy chứng nhận thiết bị

digitalSignature

Giấy chứng nhận nhà điều hành dịch vụ

cRLSign digitalSignature

9.3.9.4. Các giới hạn cơ bn

Phần m rộng giới hạn cơ bản được định nghĩa trong RFC 3280 [19], điều 4.2.1.10. Các giá trị này phải được thiết lập như sau:

Bảng 9.6 - Các trường mở rộng

Loại giấy chứng nhận

CA

pathLenConstraint

Giấy chứng nhận gốc

True

1

Giấy chứng nhận thương hiệu

True

0

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

False

-

Giấy chứng nhận nhà điều hành dịch vụ

False

-

9.3.9.5. Các khả năng của bộ xáo trộn

Các khả năng của bộ xáo trộn là một phần mở rộng riêng dành cho Cl Plus, nó phải sẵn có trong mỗi giấy chứng nhận thiết bị và được đánh dấu là quan trọng. Định nghĩa ASN.1 này được định nghĩa là:

id-pe-scramblerCapabilities OBJECT IDENTIFIER ::= {id-pe 25}

id-pe ::= {

iso(1) identified-organization(3) dod(6) internet(1) security(5)

mechanisms(5) pkix(7) 1 }

ScramblerCapabilities ::= SEQUENCE {

capability INTEGER (0..MAX),

version INTEGER (0..MAX)}

Các giá trị sau được hỗ trợ

Bảng 9.7 - Các khả năng được hỗ trợ

Giá trị

Ý nghĩa

0

DES

1

DES and AES

Các giá trị khác

Dự phòng

Trường phiên bản này được sử dụng để phân biệt hơn nữa các khả năng khác nhau của bộ xáo trộn. Xem Đặc tả về giấy phép Cl Plus [33] để biết thêm chi tiết.

9.3.9.6. Cl Plus info

Phn mở rộng riêng tùy chọn của Cl Plus info truyền thông tin bổ sung về thiết bị Cl Plus. Phn m rộng này chỉ phải sẵn có trong giy chứng nhận thiết bị và không được khai báo là quan trọng.

Định nghĩa ASN.1 của nó là

id-pe-cipluslnfo OBJECT IDENTIFIER ::= {id-pe 26 }

id-pe ::= {

iso(1) identified-organization(3) dod(6) internet(1) security(5)

mechanisms(5) pkix(7) 1}

Cipluslnfo ::= BIT STRING

Nội dung của Cipluslnfo không được tiêu chun này quy định và có thể được phần m rộng hồ sơ trong tương lai sử dụng.

9.3.9.7. Nhãn định danh thương hiệu CICAM

Phần mở rộng riêng nhãn định danh thương hiệu CICAM truyền nhận dạng của nhà sản xuất CICAM trong giy chứng nhận thiết bị Cl Plus nên được phù hợp với dòng truyền tải dành cho cơ chế ngăn chặn của máy chủ (Xem điều 10.1.1). Phần mở rộng này không được khai báo là quan trọng. Phần mở rộng này phải sẵn có trong giấy chứng nhận thiết bị CICAM.

Định nghĩa ASN.1 này là:

id-pe-cicamBrandld OBJECT INDENTIFIER ::= { id-pe 27 } id-pe ::= {

iso(1) identified-organization(3) dod(6) internet(1) security(5)

mechanisms(5) pkix(7) 1 }

CicamBrandld ::= INTEGER (1..65535)

9.3.10. signatureAlgorithm

Trường này giống Đóng dấu trong điều 9.3.3

9.3.11. signatureValue

Trường này được định nghĩa trong RFC 3280 [19], điều 4.1.1.3

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

Trong quá trình xác thực (xem điều 6), các chuỗi giấy chứng nhận được trao đi và mi thiết bị kim tra chuỗi của thiết bị kia. Phần này giải thích quá trình kiểm tra.

Giấy chứng nhận gốc Cl Plus được lưu trữ trong mỗi thiết bị, trong quá trình xác thực, chỉ có giấy chứng nhận thương hiệu và thiết bị được trao đi, giấy chứng nhận gốc không bao giờ được bất kỳ thiết bị nào trao đổi.

9.4.1. Kiểm tra giấy chứng nhận thương hiệu

Các bước sau đây phải được thực hiện đ kiểm tra giấy chứng nhận thương hiệu.

1) Kiểm tra xem tổ chức phát hành giấy chứng nhận thương hiệu có trùng với đối tượng của giấy chứng nhận gốc.

2) Kim tra thời hạn hiệu lực của giấy chứng nhận thương hiệu bao gồm ngày và thời gian hiện tại.

3) Kiểm tra xem mỗi phần mrộng bắt buộc được liệt kê trong phần 9.3.9 có tồn tại và các giá trcó hợp lệ. Kiểm tra xem không có phần m rộng khác được đánh dấu là quan trọng.

4) Kim tra xem Keyldentifier trong phn mở rộng nhãn định danh mã khóa tổ chức thẩm quyền của giấy chứng nhận thương hiệu này có giống với Keyldentifier trong phần m rộng nhãn định danh mã khóa đối tượng của giấy chứng nhận gốc.

5) Kim tra đóng dấu của giy chứng nhận bằng cách sử dụng kiểm tra RSASSA-PSS được mô ttrong RSA PKCS # 1 [1], điều 8.12.

Bảng 9.8 - Kiểm tra giấy chứng nhận thương hiệu

Thông số

Giá trị

Mã khóa công khai RSA của đóng dấu

subjectPublicKeylnfo của giấy chứng nhận gốc

Bản tin được kiểm tra

TBSCertificate của giấy chứng nhận thương hiệu (xem RFC 3280 [19], điều 4.1)

Đóng dấu được kiểm tra

signatureValue của giấy chứng nhận thương hiệu

9.4.2. Kiểm tra giấy chứng nhận thiết bị

Khi giấy chứng nhận thương hiệu được xác định là hợp lệ, giấy chứng nhận thiết b được kim tra. Quá trình này tương tự như việc kiểm tra giấy chứng nhận thương hiệu.

1) Kiểm tra xem tổ chức phát hành giấy chứng nhận thiết bị có trùng với đối tượng của giấy chứng nhận thương hiệu

2) Kiểm tra thời hạn hiệu lực của giấy chứng nhận thiết bị bao gồm thời gian hiện tại.

3) Kiểm tra xem mỗi phần mở rộng được liệt kê trong phần 9.3.9 có tn tại và các giá trị có hợp lệ. Kiểm tra xem không có phần m rộng khác được đánh dấu là quan trọng.

Kiểm tra phn m rộng nhãn định danh thương hiệu CICAM có tồn tại trong giấy chứng nhận thiết bị CICAM và nó có chứa các giá trị hợp lệ theo điều 9.3.9.7.

Lưu ý: Mặc dù phần m rộng này không được đánh du là quan trọng nhưng việc kiểm tra giấy chứng nhận sẽ bị “failnếu phần m rộng này không tồn tại hoặc chứa một giá trị không hợp lệ.

4) Kiểm tra xem Keyldentifier trong phần m rộng nhãn định danh mã khóa tổ chức thm quyền của giy chứng nhận thiết bị này có giống với Keyldentifier trong phần mrộng nhãn định danh mã khóa đối tượng của giấy chứng nhận thương hiệu.

5) Kiểm tra đóng dấu của giấy chứng nhận bằng cách sử dụng kiểm tra RSASSA-PSS được mô tả trong PKCS # 1 v2.1 [1], điều 8.1.2.

Bảng 9.9 - Kiểm tra giấy chứng nhận thiết bị

Thông số

Giá trị

Mã khóa công khai RSA của đóng dấu

subjectPublicKeylnfo của giấy chứng nhận thương hiệu

Bản tin được kiểm tra

TBSCertificate của giấy chứng nhận thiết bị (xem RFC3280 [19], điều 4.1)

Đóng dấu được kiểm tra

signatureValue của giấy chứng nhận thiết bị

6) Đảm bảo rằng giấy chứng nhận thiết bị chưa bị thu hồi, điều này chỉ được CICAM thực hiện khi kiểm tra giấy chứng nhận của máy chủ.

7) Kiểm tra xem ID của thiết bị (một phần của trường đối tượng) có chứa một giá trị hợp lệ. Xem Phụ lục B để biết chi tiết.

Các thông tin chi tiết về việc kiểm tra thu hồi danh sách có thể được tìm thấy trong Đặc tả về giấy phép Cl Plus [33].

9.4.3. Kiểm tra giy chứng nhận nhà điều hành dịch vụ

Để kiểm tra giấy chứng nhận nhà điều hành dịch vụ, các bước sau đây phải được thực hiện:

1) Kiểm tra xem tổ chức phát hành giấy chứng nhận nhà điều hành dịch vụ có trùng với đối tượng của giấy chứng nhận gốc.

2) Kiểm tra xem thời hạn hiệu lực của giấy chứng nhận nhà điều hành dịch vụ có bao gồm ngày và thời gian hiện tại.

3) Kiểm tra xem mỗi phần mở rộng bắt buộc được liệt kê trong điều 9.3.9 có tồn tại và các giá trị có hợp lệ. Kiểm tra xem không có phần mở rộng khác được đánh dấu là quan trọng.

4) Kiểm tra xem Keyldentifier trong phần mở rộng nhãn định danh mã khóa tổ chức thẩm quyền của giấy chứng nhận nhà điều hành dịch vụ này có giống với Keyldentifier trong phần mở rộng nhãn định danh mã khóa đối tượng của giấy chứng nhận gốc.

5) Kiểm tra đóng dấu của giấy chứng nhận bằng cách sử dụng kiểm tra RSASSA-PSS được mô tả trong RSA PKCS # 1 [1], điều 8.12.

Bảng 9.10 - 9.10 - Kiểm tra giấy chứng nhận nhà điều hành dịch vụ

Thông số

Giá trị

Mã khóa công khai RSA của đóng dấu

subjectPublicKeylnfo của giấy chứng nhận gốc

Bản tin được kiểm tra

TBSCertificate của giấy chứng nhận nhà điều hành dịch vụ (xem RFC3280 [19], điều 4.1)

Đóng du được kiểm tra

signatureValue của giấy chứng nhận nhà điều hành dịch vụ

6) Kiểm tra xem trình bày số ID của nhà điều hành dịch vụ trong đối tượng có phù hợp với service_operator_identity của tập tin dữ liệu thông báo thu hồi (RSD) trên bộ ghép kênh hiện tại.

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

Việc ngăn chặn dịch vụ của máy chủ cho phép nhà điều hành dịch vụ thông báo cho máy chủ sử dụng các dịch vụ có yêu cầu sự bảo vệ của CI Plus để cho phép máy chủ ngăn chặn việc hiển thị nội dung khi CICAM không tuân thủ CI Plus. Việc ngăn chặn dịch vụ của máy chủ đảm bảo rằng DVB CICAM không thể hiển thị nội dung trên các dịch vụ mà nó không được phép.

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

Thông báo dịch vụ được CI Plus bảo vệ được truyền trong Bảng mô tả dịch vụ (SDTActual) dành cho bộ ghép kênh thực tế, theo quy định tại EN 300 468 [10]. Một dịch vụ được CI Plus bảo vệ được thông báo bằng sự bao gồm của một nhãn quy định dữ liệu riêng CI Plus và ci_protection_descriptor riêng trong vòng nhãn mô tả dịch vụ của SDTActual. Nhãn mô tả này xác định xem dịch vụ có được CI Plus cho phép và có thể tùy chọn hạn chế máy chủ hoạt động với một thương hiệu cụ thể của CI Plus CICAM.

Thông báo dịch vụ được CI Plus bảo vệ là một thuộc tính trạng thái gần tĩnh của dịch vụ và không được thay đổi trên cơ sở sự kiện. Một dịch vụ có thể chuyển đổi giữa rõ ràng và được xáo trộn trên cơ sở sự kiện. Việc kiểm tra ngăn chặn dịch vụ của máy chủ hoạt động trên tất cả các dịch vụ, cả FTA và được CA xáo trộn, khi có bất kỳ CICAM trong một thiết bị máy chủ thì đảm bảo rằng thông báo truyền ngăn chặn dịch vụ này phải luôn luôn được quan trọng.

10.1.1  Nhãn mô tả được CI bảo vệ

Nhãn mô tả được CI bảo vệ (Xem Bảng 10.1) cung cấp một cách để chỉ ra chế độ hoạt động của CI được một dịch vụ yêu cầu. Nhãn này phải được chèn vào tối đa một lần trong vòng nhãn mô tả dịch vụ của SDTActual và phải đứng sau nhãn mô tả của nhãn quy định dữ liệu riêng CI Plus theo tiêu chuẩn EN 300 468 [10].

Bảng 10.1 - Nhãn mô tả được CI bảo vệ

10.1.1.1. Nhãn mô tả được CI bảo vệ

descriptor_tag: descriptor_tag dành cho ci_protection_descriptor là 0xCE.

descriptor_length: Độ dài nhãn mô tả này là một trường 8-bit xác định tổng số byte của phần dữ liệu của ci_protection_descriptor tiếp theo byte xác định giá trị của trường này.

free_ci_mode_flag: Đây là một trường 1-bit xác định chế độ hoạt động của CI. Khi được thiết lập là "0" thì chỉ ra rằng tất cả các dòng thành phần của dịch vụ không yêu cầu được CI Plus bảo vệ. Khi được thiết lập là "1" thì chỉ ra rằng tất cả các dòng thành phần của dịch vụ yêu cầu được CI Plus bảo vệ nếu chúng không được truyền rõ ràng trên mạng.

match_brand_flag: Đây là một trường 1-bit thông báo rằng nhãn mô tả này bao gồm một danh sách các CICAM_brand_identifier. Khi được thiết lập là "0" thì chỉ ra rằng dịch vụ này không la chọn các thương hiệu của CICAM. Khi được thiết lập là "1" thì chỉ ra rằng dịch vụ này đã lựa chọn thiết lập thương hiệu của CICAM. match_brand_flag chỉ phân tích khi free_ci_mode_flag được thiết lập là "1".

reserved_future_use: Các bit dự phòng này phải là "1".

number_of_entries: Trường này xác định số các cicam_brand_identifier được chứa trong vòng nhãn định danh thương hiệu. Khi trường match_brand_flag đã được thiết lập là 1 thì number_of_entries phải khác 0.

cicam_brand_identifier: Đây là một trường 16-bit nhận dạng các thương hiệu CICAM có thể được sử dụng với dịch vụ này.

Khi không có các nhãn định danh thương hiệu CICAM thì có thể sử dụng bt kỳ CI Plus CICAM với máy chủ này. Khi một hoặc nhiều nhãn định danh thương hiệu CICAM được quy định thì máy chủ chỉ phải hoạt động với thiết bị CI Plus CICAM có cicamBrandld của giấy chứng nhận thiết bị phù hợp với cicam_brand_identifier. Nếu không có các cicam_brand_identifier hiện có phù hợp với giấy chứng nhận thiết bị CICAM thì CICAM phải ngăn chặn dịch vụ này. Giá trị cicam_brand_identifier là 0x0000 được dự phòng và không được sử dụng.

private_data_byte: Trường này được bao gồm dành cho các phần mở rộng trong tương lai đối với việc ngăn chặn dịch vụ của máy chủ. Đối với tiêu chuẩn này là không xác định và nếu có trường này phải bị bỏ qua.

10.1.1.2. Nhãn mô tả của nhãn quy định dữ liệu riêng

Nhãn mô tả của nhãn quy định dữ liệu riêng (xem EN 300 468 [10], Nhãn mô tả của nhãn quy định dữ liệu riêng) phải đứng trước ci_protection_descriptor trong vòng nhãn mô tả SDTActual. Giá trị của nhãn quy định dữ liệu riêng được định nghĩa trong Đặc tả về giấy phép CI Plus [33].

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

Máy chủ phải có hai chế độ định tuyến dòng truyền tải CICAM:

1) chế độ by-pass; MPEG-2 TS phải được định tuyến trực tiếp đến Bộ giải ghép kênh máy chủ.

2) chế độ pass-through; MPEG-2 TS được định tuyến thông qua CICAM đến Bộ giải ghép kênh máy chủ.

Có hai chế độ nhận được tin cậy dành cho việc nhận SDT Actual. Trường hợp đầu tiên là trường hợp một hoặc nhiều CICAM không tuân thủ CI Plus được ghép vào máy chủ; trong trường hợp này, máy chủ phải nhận được MPEG2 TS trong chế độ by-pass để xác định xem việc được CI Plus bảo vệ có được yêu cầu dành cho dịch vụ này. Điều này được yêu cầu vì dữ liệu truyền thông qua CICAM không tuân thủ CI Plus là không đáng tin cậy.

Trường hợp thứ hai là trường hợp mà máy chủ chỉ có một CI Plus CICAM được ghép; trong trường hợp này, máy chủ sử dụng.

Trong khi nhận được MPEG-2 TS ở một trong hai phương thức nhận được tin cậy, máy chủ phải cố gắng để có được SDTActual. Nếu máy chủ nhận được MPEG-2 TS nhưng SDTActual không nhận được thì sau 5 giây, máy chủ có thể chuyển sang hoạt động ngăn chặn dịch vụ. Máy chủ phải nhận được MPEG- TS hợp lệ trước khi khởi tạo bộ đếm 5 giây để xác định xem SDTActual không tồn tại.

Khái niệm hoạt động của phần cứng dành cho chế độ by-pass của máy chủ và chế độ pass-through của CICAM được mô tả trong hình 10.1. Hình 10.1 xem nguồn dòng truyền tải có thể chuyn dưới sự kiểm soát của máy chủ. Hình này có tính tham khảo và các giải pháp phần cứng khác có thể được sử dụng để tạo ra hoạt động tương tự.

Hình 10.1 - Khái niệm hoạt động của chế độ by-pass

Việc thông báo dịch vụ được CI Plus bảo vệ của một dịch vụ là gn tĩnh và trạng thái CI Plus có thể được máy chủ lưu trữ. Máy chủ phải định kỳ xác nhận lại trạng thái dịch vụ CI Plus bằng cách kiểm tra SDTActual sử dụng chế độ nhận được tin cậy.

Nếu máy chủ lưu trữ việc thông báo dịch vụ được CI Plus bảo vệ thì nó chỉ phải lưu trữ trong khoảng thời gian tối đa là 7 ngày, sau đó dữ liệu này phải bị xóa và làm mới lại bằng cách thu nhận SDTActual phù hợp. Việc lưu trữ 7 ngày ch ra rằng một máy chủ có thể mất đến 7 ngày để phản ứng với sự thay đổi trạng thái CI Plus trong mạng.

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

Các chế độ dịch vụ được CI Plus bảo vệ được định nghĩa là:

Bảng 10.2 - Các chế độ dịch vụ được CI Plus bảo vệ

Thông báo

Loại CICAM

Chế độ hoạt động ngăn chặn dịch vụ

ci_protection_descriptor không sẵn có (Xem CHÚ THÍCH 1)

DVB CI và CI Plus

không hoạt động

ci_protection_descriptor sẵn có và free_CI_mode là 0

DVB CI và CI Plus

không hoạt động

ci_protection_descriptor sẵn có và free_CI_mode là 1

DVB CI

hoạt động

ci_protection_descriptor sẵn có, free_CI_mode là "1" và match_brand_flag là "0" hoặc number_of_entries là "0"

CI Plus

không hoạt động

ci_protection_descriptor sẵn có, free_CI_mode là "1", match_brand_flag = "1" và number_of_entries ≠ "0" và nhãn nhận dạng thương hiệu CICAM không giống

CI Plus

hoạt động

ci_protection_descriptor sẵn có, free_CI_mode là "1", match_brand_flag = 1 và number_of_entries "0" và nhãn nhận dạng thương hiệu CICAM giống nhau

CI Plus

không hoạt động

CHÚ THÍCH:

1. Không thu được SDTActual trong chế độ nhận được tin cậy thì máy chủ có thể xem là ci_protection_descriptor không sẵn có và chế độ hoạt động ngăn chặn dịch vụ không hoạt động

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

Mỗi lần thiết bị máy chủ lựa chọn một dịch vụ bất kỳ nào thì thiết bị máy chủ phải sử dụng trạng thái CI Plus của dòng truyền tải hoặc được lưu trữ từ SDTActual để xác định cách CICAM phải hoạt động với dịch vụ được lựa chọn này. Tng quan hoạt động này được thể hiện trong hình 10.2, việc lưu trữ có thể được thiết bị thu tùy chọn thực hiện.

Bất cứ khi nào máy chủ đang hoạt động (1) và lựa chọn một dịch vụ bất kỳ nào (2). Máy chủ kiểm tra xem dữ liệu thông báo dịch vụ được CI Plus bảo vệ được lưu trữ có tồn tại (3). Nếu không máy chủ chuẩn bị việc kiểm tra ngăn chặn của máy chủ và không được yêu cầu CICAM giải xáo trộn dịch vụ (4). Máy chủ chuyển sang chế độ nhận được tin cậy và thu nhận SDTActual và xác định trạng thái ngăn chặn của máy chủ có sử dụng nhãn mô tả được CI bảo vệ nếu có (5). Máy chủ cố gắng để có được SDTActual. Nếu không có được SDTActual sau 5 giây thì việc ngăn chặn dịch vụ được hoạt động (6). Máy chủ kiểm tra xem trạng thái ngăn chặn dịch vụ có đang hoạt động (7). Nếu CI_protection_descriptor không tồn tại hoặc (nếu có) free_CI_mode_flag được thiết lập là "0" thì ngăn chặn dịch vụ là chưa hoạt động (8). Nếu nhãn mô tả được CI bảo vệ tn tại và các free_CI_mode_flag thiết lập là 1 thì máy chủ phải tiếp tục kiểm tra xem dữ liệu thương hiệu có tồn tại (9). Nếu match_brand_flag được thiết lập là "0" hoặc list_length được thiết lập là 0 (không) thì máy chủ xác định rằng dữ liệu thương hiệu không tồn tại và tiếp tục kiểm tra xem CICAM có hoạt động trong một chế độ CI Plus (10). Nếu CICAM đang hoạt động trong chế độ CI Plus thì chưa kích hoạt ngăn chặn dịch vụ dành cho dịch vụ này (11), CICAM đang hoạt động trong một chế độ không tuân thủ CI Plus thì việc ngăn chặn dịch vụ được kích hoạt dành cho dịch vụ này (12). Tuy nhiên, nếu trong bước 9, match_brand_flag là 1” và list_length không bằng "0" thì máy chủ kiểm tra xem nhãn định danh của CICAM và cicam_brand_identifier được dịch vụ này thông báo có phù hợp (13), nếu nhãn định danh này không phù hợp thì ngăn chặn dịch vụ được hoạt động (12). Nếu một cicam_brand_identifier phù hợp với CICAM thì ngăn chặn dịch vụ chưa hoạt động (14).

10.4.1. Ngăn chặn dịch vụ chưa hoạt động

Ngăn chặn dịch vụ chưa hoạt động là điều kiện mà CICAM hoạt động hoặc hiện tại được phép giải xáo trộn dịch vụ này. Trong trường hợp này, dịch vụ có thể cho phép các DVB CICAM hoặc CICAM hiện tại tuân thủ CI Plus và brand_identifier phù hợp với các yêu cầu hoạt động của dịch vụ này (nếu có thể áp dụng). Xem hình 10.2 để biết thêm về ngăn chặn dịch vụ chưa hoạt động.

Khi trong chế độ hoạt động ngăn chặn dịch vụ chưa hoạt động, yêu cầu máy chủ thu nhận SDTActual phù hợp từ dòng truyền tải đ có được trạng thái hoạt động CI Plus nếu có bất kỳ trạng thái CI Plus lưu trữ cũ hơn 7 ngày, điều này có thể yêu cầu máy chủ để làm gián đoạn dịch vụ hiện đang được xem.

10.4.2. Ngăn chặn dịch vụ hoạt động

Ngăn chặn dịch vụ hoạt động là điều kiện mà CICAM hoạt động hoặc hiện tại không được phép giải xáo trộn dịch vụ này. Trong trường hợp này, CICAM có thể không tuân thủ CI Plus hay thương hiệu CICAM không phù hợp với thông báo của dịch vụ này. Việc ngăn chặn dịch vụ cũng có thể được kích hoạt tạm thời khi máy chủ thực hiện việc nhận SDT tin cậy và thu nhận nhãn mô tả được CI bảo vệ dành cho dịch vụ được lựa chọn. Xem hình 10.2 để biết thêm về ngăn chặn dịch vụ hoạt động.

Máy chủ phải thực hiện việc ngăn chặn dịch vụ bng cách khởi tạo chế độ by-pass. Nếu TS vẫn được định tuyến đến CICAM trong chế độ này thì máy chủ không được gửi CA_PMT đến CICAM.

Khi trạng thái ngăn chặn thay đổi "hoạt động" sang "chưa hoạt động" thì máy chủ phải gửi ngay lập tức CA_PMT đến CICAM.

CHÚ THÍCH 1: Việc kiểm tra ở bước (7) là kiểm tra xem nhãn CI_protection_descriptor có sẵn có ? hoặc (nếu sẵn có) kiểm tra trường “free_ci_mode_flag" có là 1 ?

CHÚ THÍCH 2: Việc kiểm tra ở bước (9) là kim tra xem trường match_brand_flag có là 1 và trường brand_identifier_length” có lớn hơn 0 (không) ?

Hình 10.2 - Hoạt động ngăn chặn

11. Giao diện lệnh

Phần này giải thích các tài nguyên mới trong CI Plus. Những thay đổi đối với tài nguyên thông tin ứng dụng hiện tại cũng được bao gồm trong phần này.

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

11.1.1. Thông tin ứng dụng phiên bản 3

Tài nguyên thông tin ứng dụng phiên bản 3 (xem Bảng L1 trong Phụ lục L dành cho ID của tài nguyên) bổ sung các lệnh mới dành cho việc thiết lập lại CICAM và các giới hạn của tốc độ dữ liệu bus của PCMCIA của máy chủ.

11.1.2. Yêu cầu thiết lập lại CICAM

Khi một điều kiện xảy ra yêu cầu CICAM phải thiết lập lại CICAM về mặt vật lý thì CICAM phải gửi request_cicam_reset APDU.

11.1.2.1. request_cicam_reset APDU

Khi nhận được yêu cầu này, máy chủ phải thiết lập lại CICAM trong vòng 10 giây. Sau khi gửi lnh request_cicam_reset, CICAM không được gửi bất kỳ APDU khác đến máy chủ.

Bảng 11.1 - Cú pháp của APDU yêu cầu thiết lập lại CICAM

Cú pháp

Số bit

Kiểu

request_cicam_reset() { request_cicam_reset_tag
length_field() = 0
}

24

uimsbf

request_cicam_reset_tag: Giá trị của thẻ này có thể được tìm thấy trong Bảng L.1 tại Phụ lục L.

Iength_field: Độ dài của ti APDU trong định dạng ASN.1 BER, xem EN 50221 [7], điều 8.3.1.

Lưu ý: CICAM cũng có thể yêu cầu giao diện vật lý được khởi tạo lại bằng cách sử dụng bit IIR của thanh ghi trạng thái. Việc hỗ trợ đối với bit IIR là tùy chọn trong CI Plus và được giải thích trong phần sau.

11.1.2.2. Yêu cầu thiết lập lại bng cách sử dụng bit IIR

Bit bổ sung được gọi là IIR (yêu cầu khởi tạo giao diện) được thêm vào thanh ghi trạng thái, xem bảng 11.2 dưới đây. CICAM thiết lập bit này đ yêu cầu thiết lập lại giao diện vật lý. Sau khi thiết lập bit IIR này, CICAM không được gửi bất kỳ APDU khác đến máy chủ. CICAM xóa bit IIR khi máy chủ thiết lập bit RS trong khi thiết lập lại.

Bng 11.2 - Thanh ghi trạng thái bao gồm IIR

Bit

7

6

5

4

3

2

1

0

 

DA

FR

R

IIR

R

R

WE

RE

Lưu ý: các bit DA, FR, WE và RE là không thay đổi, xem EN 50221 [7], phụ lục A.2.2.1.

11.1.3. Tốc độ dữ liệu trên bus PCMCIA

Tiêu chuẩn này hỗ trợ hai tốc độ dữ liệu khác nhau trên bus PCMCIA: 72 Mbit/s và 96 Mbit/s. CICAM phải hỗ trợ 96 Mbit/s. Máy chủ phải hỗ trợ 72 Mbit/s, việc hỗ trợ đối với 96 Mbit/s là tùy chọn.

11.1.3.1. data_rate_info APDU

Máy chủ gửi một data_rate_info APDU để thông báo cho CICAM về tốc độ dữ liệu tối đa mà nó hỗ trợ. Thông thường, data_rate_info APDU được gửi sau các bn tin application_info_enq và application_info khởi tạo. CICAM không được vượt quá tốc độ dữ liệu đầu ra 72 Mbit/s cho đến khi nó đã nhận được một bản tin data_rate_info từ máy chủ. Nếu data_rate_info APDU không được máy chủ gửi thì tốc độ dữ liệu tối đa được máy chủ hỗ trợ là 72 Mbit/s.

Bảng 11.3 - Cú pháp data_rate_info APDU

Cú pháp

Số bit

Kiu

data_rate_info() {

 

 

data_rate_info_tag

24

uimsbf

length_field() = 1

 

 

data_rate

8

uimsbf

}

 

 

data_rate_info: Giá trị của thẻ này là 0x9F8024.

data_rate: Giá trị này xác định tốc độ dữ liệu tối đa PCMCIA được máy chủ hỗ trợ. Bảng 11.4 liệt kê các giá trị có thể.

Bảng 11.4 - Các giá trị có thể dành cho data_rate

Tốc độ dữ liệu PCMCIA lớn nhất

Giá trị

72 Mbit/s

00

96 Mbit/s

01

Dự phòng

các giá trị khác

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

Máy chủ sử dụng tài nguyên ngôn ngữ và quốc gia của máy chủ để thông báo cho CICAM về các thiết lập ngôn ngữ và quốc gia hiện nay của nó. CICAM có thể thiết lập ngôn ngữ của trình đơn của nó để thể hiện thiết lập này của máy chủ.

Máy chủ cung cấp tài nguyên ngôn ngữ và quốc gia của máy chủ. Tài nguyên này phải hỗ trợ một phiên cho mỗi CICAM. ID của tài nguyên dành cho ngôn ngữ và quốc gia của máy chủ được liệt kê trong Bảng L.1, Phụ lục L.

11.2.1. Các APDU dành cho tài nguyên ngôn ngữ và quốc gia của máy chủ

Các APDU sau đây được tài nguyên ngôn ngữ và quốc gia của máy chủ sử dụng. Chúng được giải thích chi tiết trong các phần tiếp theo.

Bảng 11.5 - Các APDU dành cho tài nguyên ngôn ngữ và quốc gia của máy chủ

TÊN APDU

Chiu

Host_country_enq

CICAM à HOST

Host_country

CICAM ß HOST

Host_language_enq

CICAM à HOST

Host_language

CICAM ß HOST

11.2.1.1. host_country_enq APDU

CICAM gửi APDU này đến máy chủ để truy vn thiết lập về quốc gia hiện tại. Máy chủ trả lời bằng một host_country APDU.

Bảng 11.6 - Cú pháp host_country_enq APDU

Cú pháp

Số bit

Kiểu

Host_country_enq() {
Host_country_enq_tag
length_field() = 0
}


24


uimsbf

host_country_enq_tag: xem Bảng L.1, Phụ lục L.

11.2.1.2. host_country APDU

Máy chủ gửi APDU này đ thông báo cho CICAM thiết lập về quốc gia hiện tại của máy chủ. Nó được gửi để trả lời cho host_country_enq từ CICAM.

Máy chủ cũng gửi APDU này không đồng bộ khi có sự thay đổi về quốc gia của nó.

Khi mở tài nguyên ngôn ngữ và quốc gia của máy chủ, máy chủ gửi một host_country APDU đến CICAM đ truyền thiết lập hiện tại này của máy chủ.

Bảng 11.7 - Cú pháp host_country APDU

Cú pháp

Số bit

Kiểu

Host_country() {
Host_country_tag
length_field() = 3
iso_3166_country_code
}


24

24


uimsbf

bslbf

host_country_tag: xem Bảng L.1, Phụ lục L.

iso_3166_country_code: Trường này chứa thiết lập về quốc gia hiện tại của máy chủ. Mã quốc gia là một trường 24-bit xác định quốc gia của máy chủ sử dụng 3 ký tự viết hoa theo quy định của tiêu chuẩn TCVN 7217-1:2007 [17]. Mỗi ký tự được mã hóa 8-bit theo tiêu chuẩn ISO 8859-1 [15].

Chú ý: Máy chủ có thể truyền một mã quốc gia mà CICAM không hỗ trợ hoặc nhận ra, việc xử lý trạng thái này tùy thuộc vào CICAM. CICAM có thể sử dụng MMI để lựa chọn một tùy chọn phù hợp.

11.2.1.3. host_language_enq APDU

CICAM gửi APDU này đến máy chủ để truy vấn thiết lập về ngôn ngữ hiện tại. Máy chủ trả lời bằng một host_language APDU.

Bảng 11.8 - Cú pháp host_language_enq APDU

Cú pháp

S bit

Kiểu

Host_language_enq() {
Host_language_enq_tag
length_field() = 0
}


24


uimsbf

host_language_enq_tag: xem Bảng L.1, Phụ lục L.

11.2.1.4. host_language APDU

Máy chủ gửi APDU này để thông báo cho CICAM thiết lập về ngôn ngữ hiện tại của máy chủ. Nó được gửi để trả lời cho một host_language_enq từ CICAM.

Máy chủ cũng gửi APDU này không đồng bộ khi có thay đổi thiết lập về ngôn ngữ của nó.

Khi mở tài nguyên ngôn ngữ và quốc gia của máy chủ, máy chủ gửi một host_language APDU đến CICAM để truyền thiết lập về ngôn ngữ hiện tại của máy chủ.

Bảng 11.9 - Cú pháp host_language APDU

Cú pháp

Số bit

Kiểu

Host_language() {
Host_language_tag
length_field() = 3
iso_639.2_language_code
}


24

24


uimsbf

bslbf

host_language_tag: xem Bảng L.1, Phụ lục L.

iso_639.2_language_code: Trường này chứa thiết lập về ngôn ngữ hiện tại của máy chủ. Đây là một trường 24-bit xác định ngôn ngữ sử dụng 3 ký tự chữ thường theo quy định của tiêu chuẩn ISO 639 Phần 2 [18]. Cả hai tiêu chuẩn ISO 639-2/B và ISO 639-2/T có thể được sử dụng. Mỗi nhân vật được mã hóa thành 8-bit theo tiêu chuẩn ISO 8859-1 [15]. Mỗi ký tự được mã hóa 8-bit theo tiêu chuẩn ISO 8859-1 [15].

Chú ý: Máy chủ có thể truyền một mã ngôn ngữ mà CICAM không hỗ trợ hoặc nhận ra, việc xử lý trạng thái này tùy thuộc vào CICAM. CICAM có thể sử dụng MMI để lựa chọn một tùy chọn phù hợp.

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

Tài nguyên kiểm soát nội dung (CC) thực hiện các giao thức bảo mật của CI Plus như xác thực, tính mã khóa và truyền URI.

Các tài nguyên CC được máy chủ cung cấp. CICAM có thể yêu cầu một phiên dành cho tài nguyên CC chỉ khi máy chủ đã thông báo tài nguyên CC này trong giao thức quản lý tài nguyên (xem EN 50221 [7], điều 8.4.1.1). Máy chủ chỉ phải hỗ trợ một phiên dành cho tài nguyên CC đối với mỗi khe CI Plus.

ID của tài nguyên đối với tài nguyên CC được liệt kê trong Bảng L.1, Phụ lục L.

11.3.1. Các APDU dành cho tài nguyên kiểm soát nội dung

Phần này mô tả cấu trúc chung của mỗi APDU của tài nguyên CC. Điều 5 giải thích cách sử dụng các bản tin này để thực hiện các giao thức bảo mật của CI Plus.

Bảng 11.10 là một tổng quan về các APDU được tài nguyên CC sử dụng.

Bảng 11.10- Các giá trị thẻ của APDU dành cho kiểm soát nội dung

APDU_Tag

Chiều

APDU được sử dụng để

cc_open_req

CICAM => HOST

Đánh giá nội dung của máy chủ

cc_open_cnf

CICAM <= HOST

Đánh giá nội dung của máy chủ

cc_data_req

CICAM => HOST

Xác thực

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

Tính khóa SAC

cc_data_cnf

CICAM <= HOST

Xác thực

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

Tính khóa SAC

cc_sync_req

CICAM => HOST

Tính khóa SAC

cc_sync_cnf

CICAM <= HOST

Tính khóa SAC

cc_sac_data_req

CICAM <=> HOST

Tính khóa CC

Truyền và xác nhận URI

Thương lượng phiên bản URI

Truyền và xác nhận SRM

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

cc_sac_data_cnf

CICAM  <=> HOST

Tính khóa CC

Truyền và xác nhận URI

Thương lượng phiên bản URI

Truyền và xác nhận SRM

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

cc_sac_sync_req

CICAM => HOST

Tính khóa CC

cc_sac_sync_cnf

CICAM <= HOST

Tính khóa CC

cc_PIN_capabilities_req

CICAM <= HOST

Máy chủ yêu cầu các khả năng PIN của CICAM

cc_PIN_capabilities_reply

CICAM => HOST

Trả lời các khả năng PIN của CICAM

cc_PIN_cmd

CICAM <= HOST

Chuyển mã PIN sang CICAM

cc_PIN_reply

CICAM => HOST

Tr lại trạng thái mã PIN

cc_PIN_event

CICAM => HOST

Báo máy chủ biết PIN được yêu cầu

cc_PIN_playback

CICAM <= HOST

Cung cấp một PIN chơi lại cho CICAM

cc_PIN_MMI_req

CICAM <= HOST

Yêu cầu một thảo luận PIN

Cấu trúc chung của một APDU được mô tả trong EN 50221 [7], điều 8.3.1. Một APDU bắt đầu với một thẻ 24 bit theo sau là một trường độ dài được mã hóa theo ASN.1 BER.

Các giá trị thẻ của APDU dành cho tài nguyên kiểm soát nội dung được đưa ra trong Bảng L.1, Phụ lục L.

11.3.1.1. cc_open_req APDU

CICAM gửi APDU này để yêu cầu bitmask của các ID của hệ thống CC được máy chủ hỗ trợ.

Bảng 11.11 - Cú pháp APDU của bản tin cc_open_req

Cú pháp

Số bit

Kiểu

cc_open_req() {
cc_open_req_tag
length_field()=0
}


24


Uimsbf

cc_open_req_tag: xem Bảng L.1, Phụ lục L.

11.3.1.2. cc_open_cnf APDU

Máy chủ gửi APDU này cho CICAM để thông báo cho nó về ID của hệ thống CC mà nó hỗ trợ.

Bảng 11.12 - Cú pháp APDU của bản tin cc_open_cnf

Cú pháp

Số bit

Kiểu

cc_open_cnf() {
cc_open_cnf_tag
length_field()
cc_system_id_bitmask
}


24

8


uimsbf

bslbf

cc_open_cnf_tag: xem Bảng L.1, Phụ lục L.

cc_system_id_bitmask: Mỗi bit trong số 8 bit này chỉ ra sự hỗ trợ dành cho một phiên bản của hệ thống CC. CICAM có thể lựa chọn phiên bản phổ biến nhất được hỗ trợ ở cả hai đầu. Bit ít quan trọng nht là dành cho phiên bản 1, không có phiên bản 0.

Tiêu chuẩn này mô tả phiên bản 1 của CC, không phụ thuộc vào nội dung của phiên bản cc_resource. Máy chủ và CICAM phải luôn luôn thực hiện một phép toán kiểm tra trên trường này chứ không phải là so sánh đơn giản.

11.3.1.3. cc_data_req APDU

Bản tin cc_data_req được CICAM sử dụng để truyền dữ liệu liên quan đến giao thức đến máy chủ và để yêu cầu máy chủ trả lời. Dữ liệu được gửi và được yêu cầu dành cho mỗi giao thức được giải thích trong điều 11.3.2. cc_data_req được sử dụng dành cho dữ liệu không cần phải được xác thực hoặc mã hóa. Đối với dữ liệu phải được xác thực hoặc mã hóa thì sử dụng cc_sac_data_req.

Bảng 11.13 - Cú pháp APDU của bản tin cc_data_req

cc_data_req_tag: xem Bảng L.1, Phụ lục L.

cc_system_id_bitmask: xem điều 11.3.1.2

send_datatype_nbr: số các mục dữ liệu được bao gồm trong bản tin

datatype_id: xem Bng H.1, Phụ lục H, dành cho các giá trị có thể

datatype_length: giá trị này là độ dài của data_type để gửi tính theo byte

datatype: trường này được sử dụng dành cho nội dung của datatype_id.

request_datatype_nbr: số các mục dữ liệu mà máy chủ phải đưa vào trong trả lời của nó

datatype_id: danh sách các mục dữ liệu được yêu cầu trong trả lời của máy chủ, xem Bảng H.1, Phụ lục H.

11.3.1.4. cc_data_cnf APDU

Bản tin cc_data_cnf được máy chủ gửi để truyền dữ liệu liên quan đến giao thức đến CICAM. Dữ liệu chính xác với các giao thức này được quy định trong điều 5.

cc_data_cnf được sử dụng dành cho dữ liệu không cần phải được xác thực hoặc mã hóa. Nếu điều này được yêu cầu thì sử dụng cc_sac_data_cnf.

Bảng 11.14 - Cú pháp cc data_cnf APDU

cc_data_cnf_tag: xem Bảng L.1, Phụ lục L.

cc_system_id_bitmask: xem điều 11.3.1.2

send_datatype_nbr: số các mục dữ liệu được bao gồm trong bản tin này datatype_id: xem Bảng H.1 (phụ lục H) dành cho các giá trị có thể

datatype_length: độ dài của phần dữ liệu tính theo byte

data_type: phần dữ liệu thực tế

11.3.1.5. cc_sync_req APDU

Đối tượng APDU này được CICAM gửi vào phần cuối của quá trình tính mã khóa để thông báo rằng việc sử dụng mã khóa mới được tính đã sẵn sàng.

Bảng 11.15 - Cú pháp cc_sync_req APDU

Cú pháp

S bit

Kiểu

cc_sync_req() {
cc_sync_req_tag
length_field()=0
}

24

uimsbf

cc_sync_req_tag: xem Bảng L.1, Phụ lục L.

11.3.1.6. cc_sync_cnf APDU

APDU này là trả lời của máy chủ đối với cc_sync_req, nó thông báo rằng máy chủ đã hoàn thành việc tính mã khóa của nó. Để biết chi tiết, xem điều 11.3.2 bên dưới.

Bảng 11.16 - Cú pháp cc_sync_cnf APDU

Cú pháp

Số bit

Kiểu

cc_sync_cnf() {
cc_sync_cnf_tag
length_field()=1
status_field
}


24


8


uimsbf


uimsbf

cc_sync_cnf_tag: xem Bảng L.1, Phụ lục L.

status_field: byte này trả về trạng thái của máy chủ. Bảng 11.17 liệt kê các giá trị có thể.

Bng 11.17 - Các giá trị có thể dành cho status_field

status_field

Giá trị

OK

0x00

No CC Support

0x01

Host Busy

0x02

Authentication failed

0x03

CICAM Busy

0x04

Recording Mode error

0x05

Dự phòng

0x06-0xFF

11.3.1.7. cc_sac_data_req APDU

APDU này được máy chủ và CICAM sử dụng để gửi dữ liệu của giao thức cụ thể và đ yêu cầu một trả lời. Ngược lại với cc_data_req, dữ liệu được chứa trong bản tin này được xác thực và mã hóa. SAC đóng gói dữ liệu đầu vào theo quy định trong Bảng 11.19 thành tải trong bản tin SAC.

Bảng 11.18 - Cú pháp cc_sac_data_req APDU

Cú pháp

Số bit

Kiểu

cc_sac_data_req() {
cc_sac_data_req_tag
length_field()
sac_message()
}


24


uimsbf

cc_sac_data_req_tag: xem Bảng L.1, Phụ lục L.

sac_message: Định dạng của bản tin này được định nghĩa trong điều 7, Hình 7.7 và Bng 7.4. payload_encryption_flag phải là 1.

Tải của bản tin SAC này được định nghĩa trong Bảng 11.19. Để biết thêm chi tiết, xem điều 11.3.3.

Bảng 11.19 - Tải cc_sac_data_req

Cú pháp

Số bit

Kiểu

cc_system_id_bitmask
send_datatype_nbr
for (i=0; i<send_datatype_nbr; i++) {
datatype_id
datatype_length
data_type
}
request_datatype_nbr
for (i=0; i<request_datatype_nbr; i++) {
datatype_id
}

8
8

8
16
8*datatype_length

8

8

bslbf
uimsbf

uimsbf
uimsbf
bslbf

uimsbf

uimsbf

cc_system_id_bitmask: xem điều 11.3.1.2

send_datatype_nbr: số các mục dữ liệu được bao gồm trong bản tin này

datatype_id: xem Bảng H.1, Phụ lục H, dành cho các giá trị có thể

datatype_length: độ dài của dữ liệu tính theo byte

data_type: dữ liệu bản tin

request_datatype_nbr: số các mục dữ liệu mà máy chủ phải bao gồm trong trả lời đối với bản tin này

datatype_id: danh sách các mục dữ liệu được yêu cầu trong trả lời của máy chủ, xem Bảng H.1, Phụ lục H.

11.3.1.8. cc_sac_data_cnf APDU

Máy chủ và CICAM sử dụng bản tin này để gửi dữ liệu của giao thức cụ thể để trả lời đối với cc_sac_data_req () khi dữ liệu phải được xác thực và mã hóa. Điều 7 mô tả chi tiết về dữ liệu của giao thức được truyền trong mỗi bản tin. SAC đóng gói dữ liệu đầu vào này theo quy định trong Bảng 11.21 thành tải trong bản tin SAC.

Bảng 11.20 - Cú pháp cc_sac_data_cnf APDU

Cú pháp

Số bit

Kiểu

cc_sac_data_cnf() {
cc_sac_data_cnf_tag
length_field()
sac_message()
}


24


uimsbf

cc_sac_data cnf_tag: xem Bảng L.1, Phụ lục L.

sac_message: Định dạng của bản tin này được định nghĩa trong điều 7, Hình 7.7 và Bảng 7.4. payload_encryption_fIag phải là 1.

Tải của các bản tin SAC được quy định trong Bảng 11.21. Để biết thêm chi tiết, xem điều 11.3.2.

Bảng 11.21 - Ti cc_sac_data_cnf

Cú pháp

Số bit

Kiểu

cc_system_id_bitmask
send_datatype_nbr
for (i=0; i<send_datatype_nbr; i++) {
datatype_id
datatype_length
data_type
}

8
8

8
16
8*datatype_length

bslbf
uimsbf

uimsbf
uimsbf
bslbf

cc_system_id_bitmask: xem điều 11.3.1.2

send_datatype_nbr: số các mục dữ liệu được bao gồm trong bản tin này

data_type_id: xem Bảng H.1, Phụ lục H, dành cho các giá trị có thể

datatype_length: độ dài của phần dữ liệu tính theo byte

data_type: phần dữ liệu thực tế

11.3.1.9. cc_sac_sync_req APDU

APDU này được sử dụng trong quá trình tính mã khóa CC. CICAM gửi APDU này để chỉ ra rằng nó đã hoàn thành việc tính mã khóa CC mới.

Bảng 11.22 - Cú pháp cc_sac_sync_req APDU

Cú pháp

Số bit

Kiểu

cc_sac_sync_req() {
cc_sac_sync_req_tag
length_field()
sac_message()
}


24


uimsbf

cc_sac_sync_req_tag: xem Bảng L.1, Phụ lục L.

sac_message: Định dạng của bản tin này được đnh nghĩa trong điều 7, Hình 7.7 và Bảng 7.4.

payload_encryption_flagshall phải là 1. Tải của bản tin SAC này là trống.

11.3.1.10. cc_sac_sync_cnf APDU

APDU này được sử dụng trong quá trình tính mã khóa CC. Máy chủ sử dụng APDU này để trả lời đối với một cc_sac_sync_req từ CICAM.

Bảng 11.23 - Cú pháp cc_sac_sync_cnf APDU

Cú pháp

Số bit

Kiểu

cc_sac_sync_cnf() {
cc_sac_sync_cnf_tag
length_field()
sac_message()
}


24

8


uimsbf

uimsbf

cc_sac_sync_cnf_tag: xem Bảng L.1, Phụ lục L.

sac_message: Định dạng của bản tin này được định nghĩa trong điều 7, Hình 7.7 và Bảng 7.4 payload_encryption_fIagshall phải là 1.

Tải của bản tin SAC này là một trường trạng thái. Các giá trị có thể dành cho status_field được liệt kê trong Bảng 11.27

Bảng 11.24 - Các trạng thái của cc_sac_sync_cnf

status_field

Giá trị

OK

0x00

Không hỗ trợ CC

0x01

Máy chủ bận

0x02

Không được yêu cầu

0x03

Dự phòng

0x04-0xFF

11.3.2. Các APDU dành cho PIN của tài nguyên kiểm soát nội dung

Phần này quy định cụ thể các APDU dành cho PIN của tài nguyên kiểm soát nội dung cung cấp khả năng nhập PIN, xác nhận PIN dành cho ghi lại tự động và nhập PIN để phát lại vào một ngày sau đó.

11.3.2.1. Các cc_PIN_capabilities APDU

Các cc_PIN_capabilities APDU cho phép máy chủ xác định cách quản lý các mã PIN kiểm soát của cha mẹ đối với nội dung FTA và CICAM (được CAS kiểm soát).

Bảng 11.25 - Cú pháp cc_PIN_capabilities_req APDU

Cú pháp

Số bit

Kiểu

cc_PIN_capabilities_req() {
cc_PIN_capabilities_req_tag
length_field() = 0
}


24


uimsbf

cc_PIN_capabilities_req_tag: xem Bảng L.1 tại Phụ lục L.

Bảng 11.26 - Cú pháp cc_PIN_capabilities_reply APDU

Cú pháp

Số bit

Kiểu

cc_PIN_capabilities_reply() {
cc_PIN_capabilities_reply_tag
length_field()
capability_field
pin_change_time_utc
rating
}


24

8
40

8


uimsbf

uimsbf
bslbf
uimsbf

cc_PIN_capabilities_reply_tag: xem Bảng L.1 tại Phụ lục L.

capability_field: byte này trả về mã khả năng quản lý CICAM, xem Bảng 11.27.

Bảng 11.27 - Các giá trị của capability_field

capability_field

Giá trị

CICAM không có khả năng quản lý PIN

0x00

CICAM chỉ có thể quản lý PIN nội dung được điều khiển bởi CAS

0x01

CICAM có thể quản lý cả PIN nội dung được điều khiển bởi CAS và PIN nội dung không được điều khiển bởi PIN

0x02

CICAM chỉ có thể quản lý PIN nội dung không được điều khiển bởi CAS (với các PIN lưu trong CICAM)

0x03

CICAM có thể quản lý cả PIN nội dung được điều khiển bởi CAS và PIN nội dung không được điều khiển bởi PIN (với các PIN lưu trong CICAM)

0x04

Dự phòng

0x05-0xFF

Việc phân tích các giá trị capability_field được mô tả chi tiết hơn trong điều 5.11.1.

pin_change_time_utc: trả về thời gian khi CICAM PIN đã được thay đổi lần cuối. Đây là một trường 40-bit quy định ngày và thời gian theo MJD và UTC khi mã PIN đã được thay đổi lần cuối (Xem trường start_time của EIT trong EN 300 468 [10]). Trường này được mã hóa 40-bit với 16 LSB dành cho MJD và tiếp theo 24-bit được mã hóa thành 6 số theo mã 4-bit BCD. Trường này được quy định là không nếu PIN không được xử lý hoặc khi nó chưa bao giờ được thay đổi. Máy chủ có thể sử dụng "thời gian thay đổi" để cảnh báo người sử dụng cuối rằng bất kỳ việc ghi lại tự động được lập trình có thể bị thất bại khi nó đã được lập trình trước và lập lịch sau thời gian được trường pin_change_time_utc này quy định.

rating: trường 8-bit này được mã hóa theo đánh giá của DVB (độ tuổi 3+). Đánh giá này được định nghĩa trong nhãn mô tả đánh giá của cha mẹ EN 300 468 [10]. Đây là đánh giá hiện tại được thiết lập trong CICAM. Trường này cho phép máy chủ phát huy việc kiểm soát của cha mẹ khi đánh giá của máy chủ được thiết lập ở mức thấp hơn so với đánh giá của CICAM. Máy chủ có thể sử dụng cc_PIN_MMI_req () APDU dành cho mục đích này tùy thuộc vào các khả năng CICAM PIN. CICAM không được yêu cầu nhập PIN dành cho đánh giá độ tuổi thấp hơn giá trị này.

11.3.2.2. cc_PIN_cmd APDU

cc_PIN_cmd () APDU được máy chủ sử dụng để gửi CICAM PIN cho CIAM. CICAM PIN được CICAM xác nhận và cc_PIN_reply () APDU được gửi lại cho máy chủ. Máy chủ sử dụng trả lời này để kiểm tra xem CICAM PIN được lưu trữ của nó có đúng không.

Bảng 11.28 - Cú pháp cc_PIN_cmd APDU

Cú pháp

Số bit

Kiểu

cc_PIN_cmd() {
cc_PIN_cmd_tag
length_field()
for (i=0; i<n; i++) {
PINcode_data_bytes
}
}


24


8


uimsbf


uimsbf

cc_PIN_cmd_tag: xem Bảng L.1 tại Phụ lục L.

PINcode_data_bytes: tải dành cho mã PIN, một byte được sử dụng cho mỗi số của mã PIN theo định dạng ASCII.

11.3.2.3. cc_PIN_reply APDU

cc_PIN_reply () APDU được sử dụng để thông báo cho máy chủ rằng CICAM PIN được người sử dụng nhập vào là đúng hay sai.

Bảng 11.29 - Cú pháp cc_PIN_reply APDU

Cú pháp

Số bit

Kiểu

cc_PIN_reply() {
cc_PIN_reply_tag
length_field()
PINcode_status_field
}


24

8


uimsbf

uimsbf

cc_PIN_reply_tag: xem Bảng L.1 tại Phụ lục L.

PINcode_status_field: byte này trả về trạng thái quản lý của CICAM đối với mã PIN, xem Bảng 11.30.

Bảng 11.30 - Các giá trị của PINcode_status_field

PINcode_status_field

Giá trị

Lỗi -Mã PIN không chính xác

0x00

Lỗi -CICAM đang bận

0x01

Mã PIN đúng

0x02

Mã PIN không được xác nhận

0x03

Không cần làm trống tín hiệu video

0x04

Dự phòng

0x05-0xFF

Các trường này được quy định như sau:

Error - Bad PIN code: PIN được người sử dụng đầu cuối nhập vào là không chính xác và CAS sẽ không giải xáo trộn nội dung.

Error - CICAM Busy: CICAM đang bận.

PIN code correct: xác nhận rằng mã PIN được cung cấp trước đó bằng cách sử dụng cc_PIN_cmd () APDU, giao thức khởi tạo ghi lại, hoặc được người sử dụng cuối nhập vào, sử dụng MMI, là đúng.

PIN code unconfirmed: khi có nhiều hệ thống CA và không biết được hệ thống nào sẽ được sử dụng cho sự kiện được ghi lại này. Trả lời lỗi này xảy ra khi máy chủ gửi một cc_PIN_cmd () đến CICAM khi đang đăng ký việc ghi lại mà không biết hệ thống CA liên kết với sự kiện này. Máy chủ có thể tùy chọn thông báo cho người sử dụng rằng mã PIN được sử dụng để đăng ký việc ghi lại này chưa được CICAM kiểm tra.

Video blanking not required: nếu giá trị trạng thái này nhận được bằng cách sử dụng cc_PIN_event () APDU và chế độ hoạt động là ‘Watch and Buffer’ thì máy chủ không được làm trống phần AV đối vi nội dung được CA kiểm soát. Tuy nhiên, nên lưu trữ 'PIN event này với nội dung được liên kết với nó để thực thi việc kiểm soát của cha mẹ trong quá trình phát lại.

11.3.2.4. cc_PIN_event APDU

cc_PIN_event () APDU được CICAM gửi để thông báo cho máy chủ khi yêu cầu PIN để 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 () với đánh giá độ tuổi trưởng thành này dành cho việc sử dụng trong quá trình phát lại.

CICAM phải gửi cc_PIN_event () APDU đến máy chủ bất cứ khi nào đánh giá của cha mẹ thay đổi, điều này bao gồm việc chuyển đổi của mã PIN được yêu cầu và mã PIN không còn được yêu cầu, tức là đánh giá của cha mẹ đã bị loại bỏ.

Lưu ý: Nếu CICAM đã thông báo khả năng mã PIN là "0", trong quá trình trao đổi cc_PIN_capabilities, xem điều 11.3.2.1 thì CICAM không được gửi cc_PIN_event () APDU đến máy chủ.

Bảng 11.31 - Cú pháp cc_PIN_event APDU

Cú pháp

Số bit

Kiểu

cc_PIN_event() {
cc_PIN_event_tag
length_field()
program_number
PINcode_status_field
rating


24

16
8
8


uimsbf

uimsbf
uimsbf
uimsbf

pin_event_time_utc
pin_event_time_centiseconds
private_data
}

40
8
8x15

uimsbf
uimsbf
uimsbf

cc_PIN_event_tag: xem Bảng L.1 tại Phụ lục L.

program_number: số chương trình của giao thức khởi tạo ghi lại có liên kết dành cho việc ghi lại này.

PINcode_status_field: trường 8-bit này trả về trạng thái của mã PIN được gửi trước đó theo quy định tại Bảng 11.30.

rating: trường 8-bit này được mã hóa theo đánh giá của DVB (độ tuổi 3+). Đánh giá này được định nghĩa trong nhãn mô tả đánh giá của cha mẹ EN 300 468 [10]. Nó thể hiện đánh giá của mục nội dung được phát do cc_PIN_event () APDU kích hoạt.

pin_event_time_utc: Trường này tr về thời gian khi đánh giá của cha mẹ thay đổi yêu cầu nhập vào số PIN. Đây là một trường 40-bit quy định ngày và thời gian theo MJD và UTC khi đánh giá của cha mẹ thay đổi (Xem trường start_time của EIT trong EN 300 468 [10]). Trường này được mã hóa 40-bit với 16 LSB dành cho MJD và tiếp theo 24-bit được mã hóa thành 6 số theo mã 4-bit BCD.

pin_event_time_centiseconds: Trường này chứa phần trăm (giây/100) của thời gian thay đổi của đánh giá của cha mẹ yêu cầu nhập vào số PIN.

private_data: Các byte dữ liệu riêng cung cấp cho CICAM các tùy chọn để bao gồm thông tin đối với CAS cụ thể được lưu trữ và đánh giá độ tuổi trưởng thành trong quá trình ghi lại. private_data được trả về cho CICAM khi phát lại bằng cách sử dụng cc_PIN_playback () APDU.

11.3.2.5. cc_PIN_playback APDU

APDU này được gửi đến CICAM để trả lời một cc_PIN_event () APDU lúc bắt đầu phát lại và khi đánh giá của cha mẹ đối với nội dung thay đổi.

Bảng 11.32 - Cú pháp cc_PIN_playback APDU

Cú pháp

Số bit

Kiểu

cc_PIN_playback() {
cc_PIN_playback_tag
length_field()
rating
private_data
}


24

8
8x15


uimsbf

uimsbf
uimsbf

CC_PIN_ playback_tag: xem Bảng L.1 tại Phụ lục L.

rating: trường 8-bit này được mã hóa theo đánh giá của DVB (độ tuổi 3+). Đánh giá này được định nghĩa trong nhãn mô tả đánh giá của cha mẹ EN 300 468 [10].

private_data: Các byte này chứa dữ liệu riêng được truyền đến máy chủ trong cc_PIN_event () APDU.

11.3.2.6. cc_PIN_MMI_req APDU

APDU này được gửi đến CICAM để yêu cầu một MMI dành cho việc nhập mã PIN. Vòng PINcode_data_bytes cho phép máy chủ cung cấp CICAM FTA PIN (do máy chủ quản lý) hoặc CICAM PIN (do CICAM quản lý). Kết quả của việc nhập mã PIN được trả về cho máy chủ thông qua cc_PIN_reply () APDU. Xem điều 5.11.3.

Bảng 11.33 - Cú pháp cc_PIN_MMI_req APDU

Cú pháp

Số bit

Kiểu

cc_PIN_MMI_req() {
cc_PIN_MMI_req_tag
length_field()
for (i=0; i<n; i++) {
PINcode_data_bytes
}
}


24


8


uimsbf


uimsbf

cc_PIN_MMI_req_tag: xem Bảng L.1 tại Phụ lục L.

PINcode_data_bytes: Tải dành cho mã PIN, một byte được sử dụng cho mỗi số của mã pin theo định dạng ASCII.

11.3.3. Nội dung giao thức kiểm soát

Phần này giải thích tải của APDU dành cho mỗi giao thức bảo mật của CI Plus.

11.3.3.1. Đánh giá khả năng của máy chủ

Sau khi phiên dành cho tài nguyên CC đã được thành lập, CICAM yêu cầu bitmask của các ID của hệ thống CC mà máy chủ hỗ trợ. Nên lưu ý rằng máy chủ thông báo các phiên bản của tài nguyên kiểm soát nội dung được hỗ trợ bằng cách sử dụng quản lý tài nguyên và CICAM phải sử dụng tài nguyên kiểm soát nội dung có sẵn cao nht được máy chủ thông báo khi thiết lập một phiên CC.

Bảng 11.34 - Đánh giá khả năng của máy chủ

Bước

Thực hiện

APDU

Nội dung

1

CICAM yêu cầu mặt nạ bit của ID hệ thống cc của máy chủ

cc_open_req

 

2

Máy chủ gửi mặt nạ bit của ID hệ thống CC của nó

cc_open_cnf

cc_system_id_bitmask:

• bit 0 chỉ thị việc hỗ trợ CI Plus

11.3.3.2. Xác thực

Xác thực được mô tả trong điều 6.2 và tổng quan của nó được thể hiện trong hình 6.2, nó sử dụng các bn tin cc_data_req và cc_data_cnf.

Bảng 11.35 - Xác thực

Bước

Thực hiện

APDU

Nội dung

1

CICAM gửi một nonce tới máy ch

cc_data_req

send_datatype_nbr =1

i

datatype_id

datatype_len

0

19(nonce)

256 bits

request_datatype_nbr = 4

i

datatype_id

0

13 (DHPH)

1

17 (Signature_A)

2

15 (Host_DevCert)

3

7 (Host_BrandCert)

2

Máy chủ gửi một nonce, mã khóa công khai DH, đóng dấu dữ liệu của giấy chứng nhận thiết bị máy chủ và giấy chứng nhn thương hiệu máy chủ

cc_data cnf

send_datatype_nbr =4

 

i

datatype_id

 

0

13 (DHPH)

2048bits

1

17 (Signature_A)

2048bits

2

15 (Host_DevCert)

độ dài thay đổi được

3

7 (Host_BrandCert)

độ dài thay đổi được

3

CICAM gửi mã khóa công khai DH, đóng du, dữ liệu của giấy chứng nhận thiết bị CICAM và giấy chứng nhn thương hiệu CICAM

cc_data_req

send_datatype_nbr =4

i

datatype_id

datatype_len

0

14 (DHPM)

2048bits

1

18 (Signature_B)

2048bits

2

16 (CICAM_DevCert)

độ dài thay đổi được

3

8 (CICAM_BrandCert)

độ dài thay đổi được

request_datatype_nbr = 1

30

status_field

4

Máy chủ gửi một xác nhận

cc_data_cnf

send_datatype_nbr =1

i

datatype_id

datatype_len

0

30(status_field)

(Xem CHÚ THÍCH 2)

8 bits

CHÚ THÍCH

1. Xem giới thiệu tổng quan về các tham s liên quan trong Phụ lục H

2. Máy chủ có thể thiết lập là OK hoc xác thực không thành công, xem Bảng 11.17

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

Kiểm tra mã khóa xác thực được thực hiện lúc khởi tạo và sau khi hoàn thành giao thức xác thực (xem điều 6.2 và 11.3.3.2). CICAM kiểm tra xem cả hai phía có mã khóa xác thực được lưu trữ giống nhau (AKH và AKM).

Bảng 11.36 - Kiểm tra mã khóa xác thực

Bước

Thực hiện

APDU

Nội dung

1

CICAM yêu cầu mặt nạ bit của ID hệ thống CC của máy chủ

cc_open_req

 

2

Máy chủ gửi mặt nạ bit của ID hệ thống CC của nó

cc_open_cnf

cc_system_id_bitmask:

• bit 0 chỉ thị việc hỗ trợ CI Plus

11.3.3.4. Tính mã khóa CC

Giao thức này được sử dụng để tính mã khóa CC mới, xem điều 8 để biết chi tiết.

Tất cả các bản tin của giao thức này được SAC bảo vệ.

Bảng 11.37 - Tính toán mã khóa CC

Bước

Thực hiện

APDU

Nội dung

1

CICAM gửi CICAM_ID và một nonce

cc_sac_data_req

send_datatype_nbr =3

i

datatype_id

datatype_len

0

6 (CICAM_ID)

64 bits

1

12 (Kp)

256 bits

2

28 (keyregister)

8 bits

request_datatype_nbr = 2

i

datatype_id

0

5 (HOST_ID)

1

30 (Status_field)

2

Máy chủ trả lời bằng HOST_ID và một nonce

cc_sac_data_cnf

send_datatype_nbr = 2

i

datatype_id

datatype_len

0

5 (HOST_ID)

64 bits

1

30 (Status_field) (Xem CHÚ THÍCH 2)

8 bits

3

CICAM báo máy chủ biết đã hoàn thành tính mã khóa CC mới

cc_sac_sync_req

 

4

Máy chủ báo CICAM biết đã hoàn thành tính mã khóa CC mới

cc_sac_sync_cnf

Status_field (xem Bảng 11.17)

CHÚ THÍCH:

1: Xem giới thiệu tổng quan về các tham số liên quan trong Phụ lục H

2: Máy chủ có thể thiết lập giá trị là OK hoặc máy chủ bận hoặc không hỗ tr CC, xem Bảng 11.17

3: Tt cả các bản tin SAC được mã hóa và xác thực

11.3.3.5. Tính mã khóa SAC

Giao thức này được thực hiện khi phải tính mã khóa mới dành cho SAC, xem hình 7.3.

Bảng 11.38 - Tính mã khóa SAC

Bước

Thực hiện

APDU

Nội dung

1

CICAM gửi CICAM_ID và một nonce

cc_data_req

send_datatype_nbr = 2

i

datatype_id

datatype_len

0

6 (CICAM_ID)

64bits

1

21 (Ns_module)

64 bits

request_datatype_nbr = 2

i

datatype_id

0

5 (HOST_ID)

1

20 (Ns_Host)

2

Máy chủ trả lời băng HOST_ID và một nonce

cc_data_cnf

send_datatype_nbr = 2

i

datatype_id

datatype_len

0

5(HOST_ID)

64bits

1

20 (Ns_Host)

64 bits

3

CICAM báo máy chủ biết đã hoàn thành tính mã khóa SAC mới

cc_sync_req

 

4

Máy chủ báo CICAM biết đã hoàn thành tính mã khóa SAC mới

cc_sync_cnf

status_field (xem Bảng 11.20)

CHÚ THÍCH: Xem giới thiệu tổng quan v các tham số liên quan trong Phụ lục H

11.3.3.6. Truyền và xác nhận URI

Giao thức này truyền tập tin các quy tắc sử dụng (URI) và thu xác nhận của máy chủ, xem điều 5.7.5.

Bảng 11.39 - Truyền và xác nhận URI

Bước

Thực hiện

APDU

Nội dung

1

CICAM gửi URI

tới máy chủ

cc_sac_data_req

send_datatype_nbr = 2

i

datatype_id

datatype_len

0

25 (uri_message)

64 bits

1

26 (program_number)

16 bits

request_datatype_nbr = 1

i

datatype_id

0

27(uri_confirm)

2

Máy chủ gửi một xác nhận tới CICAM

cc_sac_data_cnf

send_datatype_nbr =1

i

datatype_id

datatype_len

0

27(uri_confirm)

256 bits

CHÚ THÍCH:

1: Xem giới thiệu tổng quan về các tham số liên quan trong Phụ lục H

2: Tt c các bản tin SAC được mã hóa và xác thực

11.3.3.7. Thương lượng phiên bản URI

Sau khi các mã khóa SAC đã được tính, CICAM yêu cầu một danh sách các phiên bản URI mà máy chủ hỗ trợ. Máy chủ gửi lại một bitmask các phiên bản. Mỗi bit tương ứng với một phiên bản và được thiết lập khi phiên bản này được hỗ trợ; bit ít quan trọng nhất chỉ ra sự hỗ trợ dành cho phiên bản 1. Bit quan trọng tiếp theo chỉ ra sự hỗ trợ cho phiên bản 2. Để biết thêm chi tiết, xem điều 5.7.4.

Bảng 11.40-Thương lượng phiên bản URI

Bước

Thực hiện

APDU

Nội dung

1

CICAM yêu cầu mặt nạ bit của các phiên bản URI được hỗ trợ từ máy chủ

cc_sac_data_req

request_datatype_nbr = 1

i

datatype_id

0

29(uri_versions)

2

Máy chủ gửi mặt nạ bit của các phiên bản URI được hỗ trợ

cc_sac_data_cnf

send_datatype_nbr = 1

i

datatype_id

datatype_len

0

29(uri_versions)

256 bits

CHÚ THÍCH:

1: Xem giới thiệu tổng quan về các tham số liên quan trong Phụ lục H

2: Tất cả các bn tin SAC được mã hóa và xác thực

11.3.4. 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 giá trị EMI là 0b11, CICAM có thể tùy chọn cung cấp một giấy phép tại lúc 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 này dành cho thời gian sống của việc ghi lại. Nếu một giấy phép tồn tại dành cho một mục của nội dung thì giấy phép này phải được CICAM gốc kiểm tra bởi khi nội dung này được phát lại để xem nếu các quyền để xem nội dung vẫn còn tồn tại. Giấy phép được CICAM cung cấp chứa dữ liệu dành cho CAS cụ thể được máy chủ lưu trữ cùng với nội dung này. Khi mục của nội dung này được phát lại thì máy chủ phải truyền giấy phép này trở lại CICAM gốc mà không có bất kỳ thay đổi nào.

Các giấy phép luôn luôn được trao đổi thông qua SAC bng cách sử dụng các giao thức dưới đây.

11.3.4.1. Giao thức trao đổi giấy phép từ CICAM đến máy chủ

Nếu yêu cầu một giấy phép 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 chủ giấy phép này bng cách sử dụng SAC. Quá trình này sử dụng giao thức trao đổi giấy phép từ CICAM đến máy chủ và trình bày sau đây bao gồm cả trả lời.

Bảng 11.41 - Giao thức trao đổi giấy phép từ CICAM đến máy chủ

Bước

Thực hiện

APDU

Nội dung

1

CICAM cung cấp giấy phép nội dung cho máy chủ

cc_sac_data_req

send_datatype_nbr = 3 or 4

i

datatype_id

datatype_len

0

26 (program_number) (Xem CHÚ THÍCH 3)

16 bits

1

34 (license_status)(Xem CHÚ THÍCH 4)

8 bits

2

25 (uri_messaqe)

64 bits

3

33 (cicam_license)

variable

request_datatype_nbr = 1

i

datatype_id

0

35(license_rcvd_status)

2

Máy chủ xác nhận đã nhận được

cc_sac_data_cnf

send_datatype_nbr = 1

i

datatype_id

datatype ten

0

35 (license_rcvd_status)(Xem CHÚ THÍCH 5)

8 bits

CHÚ THÍCH

1: Xem giới thiệu tổng quan v các tham số liên quan trong Phụ lục H

2: Tt c các bn tin SAC được mã hóa và xác thực

3: Giá trị program_number này trùng với giá trị program_number của bản tin Bắt đầu ghi

4: Bảng 11.45 chứa các giá trị cho phép vá ý nghĩa của trường này

5: Bảng 11.42 cha các giá trị cho phép và ý nghĩa của trưng này

Bảng 11.42 - Các giá trị license_rcvd_status

license_rcvd_status

Giá trị

OK

0x00

Máy chủ bận

0x01

Dữ liệu không hợp lệ

0x02

Lỗi máy chủ

0x03

Dự phòng

0x04-0xFF

11.3.4.2. Giao thức trao đi giấy phép phát lại

Khi một mục của nội dung được kết hợp với một giấy phép, tại lúc được phát lại, máy chủ phải cung cấp cho CICAM giấy phép gốc. CICAM xử lý giấy phép này để thiết lập xem máy chủ vẫn có quyền phát lại nội dung này. Một giấy phép và URI mới được trả về cho máy chủ để thay thế bản gốc trong trường hợp thông tin đã bị thay đổi, ví dụ như số lượt phát lại.

Độ dài của cicam_license và host_license phải giống nhau, nghĩa là giấy phép phát lại nhận được từ CICAM phải có độ dài giống như host_license gốc đã được gửi đến CICAM khi phát lại.

Bảng 11.43 - Giao thức trao đổi giấy phép phát lại

Bước

Thực hiện

APDU

Nội dung

1

Máy chủ cung cấp giấy phép CICAM

cc_sac_data_req

send_datatype_nbr = 2

i

datatype_id

datatype_len

0

26 (program_number)

16 bits

1

36(Host_license)

variable

request_datatype_nbr = 4

i

datatype_id

0

26 (program_number)

1

34 (license_status)

2

25 (uri_message)

3

33(cicam_license)

2

CICAM trả lời bng giấy phép và URI mới

cc_sac_data_cnf

send_datatype_nbr = 4

i

datatype_id

datatype_len

0

26 (program_number)

16 bits

1

34 (license_status)(Xem CHÚ THÍCH 3)

8 bits

2

25 (uri_message)

64 bits

3

33 (cicam_license)

variable

CHÚ THÍCH:

1: Xem giới thiệu tổng quan về các tham số liên quan trong Phụ lục H

2: Tất cả các bản tin SAC được mã hóa và xác thực

3: Bảng 11.45 chứa các giá trị cho phép và ý nghĩa của trường này

11.3.4.3. Giao thức trao đổi kiểm tra giấy phép

Khi máy chủ cần trao đổi với CICAM về trạng thái hiện tại của một giấy phép nội dung có liên kết với việc ghi lại thì nó thực hiện theo giao thức sau đây.

Trả lời từ CICAM chứa thông tin liên quan đến trạng thái của giấy phép đã được gửi trong yêu cầu. Trả lời này chỉ mang tính tham khảo, ví dụ như để cung cấp chi tiết hơn về nội dung sẵn có khi hiển thị một thư mục ghi lại.

Bảng 11.44 - Giao thức trao đổi kiểm tra giấy phép

Bước

Thực hiện

APDU

Nội dung

1

Máy chủ cung cấp giấy phép CICAM

cc_sac_data_req

send_datatype_nbr = 1

i

datatype_id

datatype_len

0

36 (Host_license)

variable

request_datatype_nbr = 2

i

datatype_id

0

34 (license_status)

1

37 (play_count)

2

CICAM trả lời bằng trạng thái giấy phép và play_count

cc_sac_data_cnf

send_datatype_nbr = 2

i

datatype_id

datatype_len

0

34 (license_status) (Xem CHÚ THÍCH 3)

8 bits

1

37 (play_count)

8 bits

CHÚ THÍCH:

1: Xem giới thiệu tổng quan về các tham số liên quan trong Phụ lục H

2: Tất cả các bản tin SAC được mã hóa và xác thực

3: Bảng 11.45 chứa các giá trị cho phép và ý nghĩa của trường này

Bảng 11.45 - Các giá trị license_status

license_status

Giá trị

OK

0x00

Không thể giải xáo trộn, không sử dụng (chỉ ghi lại)

0x01

Không thể giải xáo trộn, lỗi không xác định (chỉ ghi lại)

0x02

Các quyền sử dụng hết hạn (xem & kiểm tra trạng thái)

0x03

Số lượt phát lại vượt quá (xem & kim tra trạng thái)

0x04

Giới hạn lưu giữ vượt quá (xem & kiểm tra trạng thái)

0x05

Giấy phép không hợp lệ (xem & kiểm tra trạng thái)

0x06

Dự phòng

0x07-0xFF

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

Máy chủ thông báo sự bắt đu của một dịch vụ được CA bảo vệ ghi lại cho CICAM thông qua giao thức sau đây bằng cách sử dụng SAC. Việc trao đổi này cũng thông báo cho CICAM chế độ hoạt động hiện tại của máy chủ.

Trường hợp máy chủ là trong chế độ hoạt động "Unattended_Recording" hoặc "Watch_and_Buffer" thì tham số PINcode_data được sử dụng để cung cấp cho CICAM mã CICAM PIN. CICAM PIN chỉ phải được sử dụng để cho phép ghi lại tự động khi một sự kiện kiểm soát của cha mẹ 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 khi phát lại và xem trực tiếp; trong trường hợp này phải yêu cầu người sử dụng nhập CICAM PIN bằng MMI cp cao hoặc ứng dụng.

Bảng 11.46 - Giao thức khởi tạo ghi lại

Bước

Thực hiện

APDU

Nội dung

1

Máy chủ thông báo cho CICAM bắt đầu ghi lại

cc_sac_data_req

send_datatype_nbr = 2 or 3

i

datatype_id

datatype_len

0

38 (operating_mode)

8 bits

1

26 (program_number)

16 bits

2

39 (PINcode data)

variable (tùy chọn)

request_datatype_nbr = 1

i

datatype_id

0

40 (record_start_status)

2

CICAM gửi xác nhận đến máy chủ

cc_sac_data_cnf

send_datatype_nbr = 1

i

datatype_id

datatype_len

0

40 (record_start_status) (Xem CHÚ THÍCH 4)

8 bits

CHÚ THÍCH:

1: Xem giới thiệu tổng quan về các tham số liên quan trong Phụ lục H

2: Tất cả các bản tin SAC được mã hóa và xác thực

3: Bảng 11.47 chứa các giá trị cho phép và ý nghĩa của trường này

4: Bảng 11.17 chứa các giá trị cho phép của trường này

Bảng 11.47 - Các giá trị operating_mode

operating mode

Giá trị

Xem và đệm (Watch_and_Buffer)

0x00

Chế độ tạm dừng (Timeshift)

0x01

Ghi laji tự động (Unattended_Recording)

0x02

Dự phòng

0x03-0xFF

Các chế độ hoạt động này được mô tả như sau:

Watch_and_Buffer - người sử dụng đang xem trực tiếp nội dung đang được ghi lại. Khi nhận được bản tin khởi tạo ghi lại, CICAM phải lưu trữ CICAM PIN để cho phép ghi lại tự động khi đánh giá độ tui trưởng thành thay đổi. CICAM phải tiếp tục hiển thị một MMI để yêu cầu người sử dụng nhập vào CICAM PIN khi yêu cầu thực hiện việc đánh giá độ tuổi trưởng thành. CICAM phải tiếp tục giải xáo trộn nếu CICAM PIN được lưu trữ là chính xác và máy chủ phải làm trống video và âm thanh khi nhận được cc_PIN_event () có PINcode_status_field là "0x00" cho đến khi cc_PIN_reply APDU tiếp theo ()

PINcode_status_field là "0x02".

Timeshift - người sử dụng đang xem nội dung được ghi lại trước đó trong khi máy chủ tiếp tục ghi lại nội dung trực tiếp. CICAM không được cung cấp một MMI dành cho việc nhập CICAM PIN và phải sử dụng CICAM PIN được lưu trữ để tiếp tục giải xáo trộn nội dung được ghi lại tự động. Máy chủ phải sử dụng cc_PIN_playback () APDU khi xem nội dung được ghi lại và lưu trữ để thông báo cho CICAM đánh giá độ tuổi trưởng thành đối với nội dung đang được phát lại. Máy chủ phải làm trống video và âm thanh cho đến khi nhận cc_PIN_reply () APDU có PINcode_status_field là "0x02".

Unattended_Recording - người sử dụng đã lập lịch cho máy chủ ghi lại nội dung trong một chế độ tự động. Trước khi lập lịch ghi lại, máy chủ có thể xác nhận CICAM PIN được lưu trữ bằng cách sử dụng cc_PIN_cmd () APDU. Tại lúc bắt đầu ghi lại, máy chủ gửi CICAM PIN trong bản tin khởi tạo ghi lại đến CICAM. Trong quá trình ghi lại, CICAM thông báo cho máy chủ về trạng thái độ tuổi trưởng thành bằng cách sử dụng cc_PIN_event () APDU để máy chủ sử dụng khi phát lại.

11.3.4.5. Giao thức chế độ hoạt động thay đổi

Giao thức sau đây được sử dụng khi máy chủ thay đổi chế độ hoạt động và được so sánh với bản tin khởi tạo ghi lại. Bản tin chế độ hoạt động thay đổi được sử dụng trong trường hợp không có giấy phép mới ví dụ như chế độ hoạt động thay đổi từ "Watch_and_Buffer" sang "Timeshift".

Bảng 11.48 - Giao thức chế độ hoạt động thay đổi

Bước

Thực hiện

APDU

Nội dung

1

Máy chủ thông báo cho CICAM về sự thay đổi chế độ hoạt động

cc_sac_data_req

send_datatype_nbr = 2

i

datatype_id

datatype_len

0

38 (operating_mode)

8 bits

1

26 (program_number)

16 bits

request_datatype_nbr = 1

i

datatype_id

0

41 (mode_change_status)

2

CICAM gửi xác nhận đến máy chủ

cc_sac_data_cnf

send_datatype_nbr = 1

i

datatype_id

datatype_len

0

41 (mode_change_status)

8 bits

CHÚ THÍCH:

1: Xem giới thiệu tổng quan về các tham số liên quan trong Phụ lục H

2: Tất cả các bản tin SAC được mã hóa và xác thực

3: Bảng 11.47 chứa các giá trị cho phép và ý nghĩa của trường này

4: Bng 11.17 cha các giá trị cho phép của trưng này

11.3.4.6. Giao thức dừng ghi lại

Máy chủ sử dụng giao thức này để thông báo cho CICAM rằng việc ghi lại đã được dừng lại và tất cả các thông tin liên quan đến mã PIN được CICAM lưu trữ phải bị xóa.

Bảng 11.49 - Giao thức dừng ghi lại

Bước

Thực hiện

APDU

Nội dung

1

Máy chủ thông báo cho CICAM rằng việc ghi lại đã bị dừng

cc_sac_data_req

send_datatype_nbr = 1

i

datatype_id

datatype_len

0

26 (program_number)

16 bits

request_datatype_nbr = 0

i

datatype_id

0

42 (record_stop_status)

2

CICAM gửi xác nhận đến máy chủ

cc_sac_data_cnf

send_datatype_nbr = 1

i

datatype_id

datatype_len

0

42 (record_stop_status) (Xem CHÚ THÍCH 3)

8 bits

CHÚ THÍCH:

1: Xem giới thiệu tổng quan về các tham số liên quan trong Phụ lục H

2: Tất c các bn tin SAC được mã hóa và xác thực

3: Bảng 11.17 chứa các giá trị cho phép của trường này

11.3.5. Truyền và xác nhận tập tin SRM

Giao thức truyền tập tin dữ liệu này truyền các tập tin dữ liệu như tập tin dữ liệu SRM và thu trạng thái và xác nhận của máy chủ. Giao thức này sử dụng các CI Plus SAC APDU để gửi các tập tin dữ liệu từ CICAM đến máy chủ. Tập tin dữ liệu này được xác định bằng một datatype_id (xem bảng H.1 trong Phụ lục H dành cho datatype_id chỉ ra một tập tin SRM). Thông tin chi tiết được giải thích trong bảng 11.50.

Bảng 11.50 - Truyền và xác nhận tập tin SRM

Bước

Thực hiện

APDU

Nội dung

1

CICAM gửi SRM đến máy chủ

cc_sac_data_req

send_datatype_nbr = 1

i

datatype_id

 

0

31 (srm_data)

 

request_datatype_nbr = 2

i

datatype_id

0

30 (status_field)

1

32 (datatransfer_confirm)

2

Máy chủ gửi xác nhận đến CICAM

cc_sac_data_cnf

send_datatype_nbr = 2

i

datatype_id

datatype_len

0

30 (status_field) (Xem CHÚ THÍCH 3)

8 bits

1

32 (datatransfer_confirm)

256 bits

CHÚ THÍCH:

1: Xem giới thiệu tổng quan về các tham số liên quan trong Phụ lục H

2: Tất cả các bản tin SAC được mã hóa và xác thực

3: Máy chủ có thể thiết lp là OK, máy chủ bận hoặc không yêu cầu, xem Bng 11.24

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

CI Plus cung cấp một tài nguyên hỗ trợ ứng dụng cụ thể (SAS) tương tự như tài nguyên này được quy định trong các bản quy định kỹ thuật OpenCable ™, giao diện 2.0 CableCARD ™ [27]. Tài nguyên này cung cấp một ống trong suốt cho phép một ứng dụng trên máy chủ truy nhập chức năng trên CICAM.

Đối với tài nguyên SAS có ích, một giao thức phải được xác định trên đầu của ống trong suốt này. Mỗi một giao thức được gán một private_host_application_ID để nhận dạng nó duy nhất.

Tài nguyên SAS được áp dụng cho các MHP CA API cho phép trao đổi dữ liệu giữa môi trường ứng dụng MHP và CAS cư trú trên CICAM như mô tả trong hình 11.2.

Hình 11.1 - Ví dụ môi trường ứng dụng dành cho SAS

Giao thức bản tin tài nguyên SAS dành cho các MHP CA API được quy định tại Phụ lục M.

APDU và cú pháp bản tin của tài nguyên SAS trong các bản quy định kỹ thuật OpenCable ™, giao diện 2.0 CableCARD ™ [27], điều 9.17, phải được hồ sơ này định nghĩa và sử dụng.

CICAM phải mở một phiên SAS lúc khởi tạo. Khi máy chủ yêu cầu một kết nối đến một ứng dụng trên CAM, nó gửi một SAS_connect_rqst () APDU theo điều 9.17.1 của [27] để một phiên SAS chưa được sử dụng.

APDU này bao gồm private_host_application_ID được yêu cầu. Nếu CICAM hỗ trợ ID của ứng dụng được yêu cầu thì nó liên kết phiên SAS này với ID của ứng dụng này và gửi trả một SAS_connect_cnf () APDU. Sau đó CICAM phải mở một phiên SAS khác dành cho các kết nối tiếp theo của máy chủ để có ít nht một phiên SAS được mở có sẵn và không liên kết đến một ID ứng dụng.

Máy chủ phải theo dõi các mối liên kết giữa mỗi phiên SAS và một ID ứng dụng. Khi máy chủ muốn kết nối với một ID ứng dụng, nó phải sử dụng một phiên SAS được mở và chưa được liên kết với một ID ứng dụng.

CICAM có thể hỗ trợ nhiều máy khách được kết nối với cùng một ID ứng dụng tại cùng một lúc.

11.4.1. Thời gian sống của ứng dụng

Mỗi ứng dụng của máy chủ yêu cầu truy nhập tài nguyên SAS phải tạo ra một kết nối SAS mới và thời gian sống của ứng dụng vi tài nguyên SAS này được định nghĩa như sau:

1) ng dụng khởi tạo trên máy chủ.

2) ng dụng của máy chủ khởi tạo một kết nối với phiên SAS bng một SAS_connect_rqst () APDU khi yêu cầu một kết nối.

3) CICAM xử lý yêu cầu và trả lời bằng một SAS_connect_cnf () APDU.

• Nếu kết nối này đã được chấp nhận thì CICAM phải tạo một phiên SAS mới sẵn sàng dành cho bất kỳ kết nối mới tiếp theo.

• Nếu kết nối này không được chấp nhận thì phiên này vẫn mở sẵn sàng dành cho một yêu cầu kết nối tiếp theo.

4) ng dụng của máy chủ và CICAM thông báo qua phiên SAS được kết nối này.

5) ng dụng của máy chủ kết thúc và phiên SAS này được máy chủ đóng lại.

11.4.2. Truyền dữ liệu

Chỉ sử dụng chế độ không đồng bộ để chuyển dữ liệu CI Plus theo quy định tại Đặc tả kỹ thuật về giao diện OpenCable phiên bản 2.0 [27]. Chế độ đồng bộ thì không được hỗ trợ.

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

12.4. Phạm vi

TS 101 699 [8] điều 6.5 quy định khái niệm MMI miền ứng dụng. MMI miền ứng dụng này cho phép một công cụ trình bày chưa được quy định được sử dụng (nếu có) cho phép thực hiện trình bày và tương tác ứng dụng đặc biệt của CICAM khi so sánh với MMI ứng dụng cp cao thông thường.

Hình 12.1 - Hoạt động của công cụ trình bày CI Plus và tài nguyên MMI ứng dụng

Phần này quy định hồ sơ ứng dụng CI Plus được thực hiện trong một máy chủ CI Plus và xác định chức năng tối thiểu mà máy chủ phải hỗ trợ.

Một công cụ trình bày CI Plus chuẩn bắt buộc cho phép mô-đun này trình bày ký tự và đồ họa trên màn hình của máy chủ mà không cần có các phần mở rộng đối với các tài nguyên MMI có thể hạn chế ứng dụng này của mô-đun. Phạm vi của một máy chủ tuân thủ CI Plus được mô tả trong hình 12.2. Công cụ trình bày CI Plus này cho phép mô-đun này trình bày thông tin với cái nhìn và cảm nhận được nhà điều hành dịch vụ quy định chứ không phải bị MMI cấp cao hạn chế vì MMI này có kiểm soát trình bày và tương tác hạn chế.

Hình 12.2 - Phạm vi của CI Plus

MMI ứng dụng CI Plus được dựa trên bn quy định kỹ thuật công cụ UK-DTT MHEG-5 [23] và là nhóm cung cấp chức năng đầy đủ để cho phép một ứng dụng của mô-đun trình bày ký tự và đồ họa với sự kiểm soát tối thiểu lên dòng truyền tải. Tất cả nội dung đến công cụ trình bày CI Plus phải được CICM cung cấp cho máy chủ trực tiếp thông qua tài nguyên MMl ứng dụng: CICAM có thể tùy chọn tự tạo tập tin dữ liệu và/hoặc tạo trực tiếp từ dòng truyền tải.

MMI ứng dụng CI Plus có thể hoạt động trong một máy chủ có hỗ trợ các môi trường ứng dụng khác ví dụ như MHEG-5, MHP, v.v.. Việc thực hiện MMI ứng dụng CI Plus của máy chủ có thể lựa chọn để hỗ trợ giao diện sử dụng bất kỳ môi trường ứng dụng MHEG-5 hiện có nào hoặc thực hiện riêng biệt. MMI ứng dụng CI Plus phải được ưu tiên hơn bt kỳ môi trường ứng dụng hiện có nào và có thể tùy chọn được trình bày trên màn hình đồ họa riêng của máy chủ, màn hình ứng dụng hoặc một màn hình khác có thể tồn tại giữa màn hình riêng của máy chủ và màn hình ứng dụng, điều này được thể hiện trong hình 12.3

Hình 12.3 - Các màn hình hiển thị

Hình 12.3 chỉ là tham khảo và bao gồm c màn hình lôc và vật lý, việc thực hiện của máy chủ phải xác định ánh xạ vật lý phù hợp nhất dành cho một kiến trúc máy chủ nhất định. MMI ứng dụng phải hỗ trợ video đầy đủ cho phép ký tự và đồ họa được ph trong suốt trên video (và có thể là trên bất kỳ màn hình ứng dụng riêng nào). MMI ứng dụng có độ phân giải SD gốc 720x576 pixel và phải được mở rộng toàn màn hình để phù hợp với khuôn dạng hình ảnh hiện tại trong cả hai môi trường SD và HD.

Việc cung cấp kiểm soát bị hạn chế trên các bộ giải mã MPEG cho phép video và âm thanh của dịch vụ hiện tại này được trình bày là bắt buộc đối với MMI ứng dụng, có thể sử dụng bổ sung một I-frame có khung hình đầy đ để cung cấp nền đồ họa phong phú. MMI ứng dụng có thể từ chối việc kiểm soát MMI ứng dụng của bộ giải mã MPEG nếu một xung đột tài nguyên xảy ra.

Hồ sơ MMI ứng dụng bao gồm một phần mở rộng tùy chọn dành cho phông chữ phác thảo TrueType và OpenType tự động nạp cho phép các bộ ký tự quốc tế được ứng dụng này sử dụng. Phông chữ tự động nạp có thể không có sẵn trong tất cả các máy chủ và ứng dụng này có thể kiểm tra sự hỗ trợ của máy chủ từ bên trong ứng dụng.

Tiêu chuẩn này mở rộng MMI ứng dụng bao gồm hỗ trợ tính năng dành cho các ứng dụng loại VOD.

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

ng dụng CI Plus phải tuân thủ hồ sơ MHEG-5 phiên bản 1.06 [D-Book 5.0, điều 12-18] [23] với một số chức năng được giảm bớt dành cho máy chủ tuân thủ CI Plus.

12.2.1. Miền ứng dụng

Tiêu chuẩn này là một miền ứng dụng trong các điều khoản nêu tại Phụ lục D của tiêu chuẩn ISO 13.522-5 [16] và D-Book 5.0 [23] Điều 13. Miền ứng dụng của CI Plus được gọi là "CIEngineProfile1".

12.2.2. Tập các lớp

Tập các lớp được định nghĩa trong D-Book 5.0 [23], 13.3 với các trường hợp ngoại lệ được ghi trong Bảng 12.1:

Bảng 12.1 - Các trường hợp ngoại lệ đi với các lớp D-Book 5.0

Lớp

Ghi chú

Phông chữ

Bắt buộc (Xem CHÚ THÍCH)

Nghệ thuật đường thẳng động

Không bắt buộc.

HyperText

Không bắt buộc.

CHÚ THÍCH: Xem D-Book[23] and điều 12.5.1 Các phông chữ có thể tải về

Thiết bị thu có thể tùy chọn hỗ trợ các lớp "Không bắt buộc" nhưng chúng không được ứng dụng CI Plus sử dụng trừ khi được tham chiếu trong bối cảnh của một miền ứng dụng khác nhau hoặc ứng dụng này đã xác nhận lớp đó tồn tại.

12.2.3. Tập các tính năng

Tập các tính năng được xác định trong D-Book 5.0 [23], điều 13.4 với các trường hợp ngoại lệ sau đây trong Bảng 12.2:

Bảng 12.2 - Các trường hợp ngoại lệ của CIEngineProfile1GetEngineSupportbehaviour đối với D-Book 5.0

Tính năng

Ghi chú

Lưu tạm thời

Không bắt buộc.

Co dãn tín hiệu video

Không bắt buộc.

Tỷ số kích thước hình ảnh

Không bắt buộc.

UniversalEngineProfile

Phải đi kèm với D-Book và có thể hỗ trợ giá trị hồ sơ CI Plus.

Một hồ sơ MHEG đầy đủ thường bao gồm đối tượng dòng cung cấp việc kiểm soát của các thành phần âm thanh và video. Để duy trì video và âm thanh hiện tại, một ứng dụng thường tạo một đối tượng dòng có chứa âm thanh và video được thiết lập theo các thành phần mặc định. Sau đó ứng dụng có thể thay đổi các thẻ của thành phần để chọn các thành phần âm thanh và video. Đối với hồ sơ CI Plus, chỉ cho phép ứng dụng này sử dụng các thành phần video và âm thanh mặc đnh. Cho phép ứng dụng CI Plus dừng lại và bắt đầu dòng để hiển thị một I-frame nếu nó được cho phép sử dụng chương trình thường trú RequestMPEGDecoder.

Các thành phần mặc định được thiết lập không kể các thành phần hiện đang hoạt động trên thiết bị thu. Việc tải về một ứng dụng CI Plus với tập các thành phần mặc định không được làm thay đổi chúng. Các thành phần hiện tại có thể đã được thiết lập bởi một môi trường ứng dụng, chẳng hạn như MHP, và không được ứng dụng CI Plus can thiệp.

12.2.3.1. Hồ sơ công cụ CI Plus

UniversalEngineProfile phải trả lời bằng xác nhận đối với một đối số kiu chuỗi "CIPLUS001" xác định công cụ MHEG này là tuân th hồ sơ CI Plus 1.

12.2.3.2. Tính năng không bắt buộc

Các tính năng được xác định là không bắt buộc trong hồ sơ này có thể được máy chủ phù hợp với hồ sơ này tùy chọn thực hiện. Điều này cho phép hồ sơ CI Plus cùng tồn tại với các hồ sơ MHEG-5 khác.

Các ứng dụng CI Plus không được sử dụng bt kỳ tính năng được xác định là không bắt buộc trừ khi ứng dụng này kiểm tra xem nó có được công cụ này sử dụng UniversalEngineProfile () hoặc bất kỳ một phương pháp tiêu chuẩn khác để xác định các khả năng của môi trường này hỗ trợ.

Công cụ này chỉ có thể cung cấp các tính năng tùy chọn từ một (nhiều) hồ sơ khác đã được chứng nhận ví dụ như các tính năng của hồ sơ New Zealand MHEG có thể hoạt động nếu máy chủ được chứng nhận dành cho New Zealand.

12.2.3.3. Các đối tượng dòng

ng dụng này phải bắt đầu với các thành phần mặc định hoạt động bằng cách xác định một đối tượng dòng chứa các đối tượng âm thanh và video hoạt động được thiết lập theo thành phần mặc định. Nếu ứng dụng CI Plus muốn ngăn chặn dòng thì đầu tiên nó phải được cho phép sử dụng chương trình thường trú RequestMPEGDecoder, xem điều 12.3.6.

Yêu cầu sự cho phép của RequestMPEGDecoder khi các môi trường ứng dụng khác hiện tại đang sử dụng bộ giải mã MPEG có thể đang chạy.

Bất kỳ ứng dụng nào không bắt đầu với một đối tượng dòng hoạt động với các thành phần mặc định phải bị xử lý theo một cách không xác định.

Bất kỳ nỗ lực nào ngăn chặn đối tượng video hoặc toàn bộ dòng mà không được phép phải bị xử lý theo một cách không xác định.

Khi được cho phép, việc kiểm soát của các bộ giải mã MPEG phải tuân theo các quy tắc ứng dụng cư trú bình thường hoặc cho đến khi ứng dụng CI Plus này giải phóng nó bằng cách sử dụng RequestMPEGDecoder. Trước khi giải phóng bộ giải mã MPEG này, ứng dụng này phải trả bộ gii mã MPEG về trạng thái bình thường của nó bằng cách loại bỏ bt kỳ I-frame khỏi màn hình và khởi tạo lại các đối tượng với các thẻ thành phần video và âm thanh mặc định.

Cơ chế này đảm bảo rằng ứng dụng này hoạt động theo cách có thể đoán được trước ngay cả khi một môi trường ứng dụng đang hoạt động.

Hồ sơ CI Plus không yêu cầu các đối tượng dòng tạo các sự kiện dòng.

12.2.3.4. RTGraphics/phụ đ

Khi khởi tạo MMI ứng dụng CI Plus, trạng thái của phụ đề phải được xác định từ bản tin khởi tạo yêu cầu CICAM được xác định trong điều 13.6.2. Trường hợp dừng phụ đề để cho phép khởi tạo MMI ứng dụng CI Plus thì phụ đề phải được kích hoạt lại tự động khi ứng dụng CI Plus kết thúc.

12.2.4. GetEngineSupport

Các "tính năng" của GetEngineSupport trong D-Book 5.0 [23] điều 13.4.1 với các ngoại lệ trong bảng 12.3:

Bảng 12.3 - Các tính năng” của GetEngineSupport

Chuỗi

Giới hạn

Tiêu chun

Ngắn

MultipleAudioStreams(N)

MAS(N)

Có thể trả giá trị “true" với N≤1

MultipleVideoStreams(N)

MVS(N)

Có thể trả giá trị “true" với N≤1

VideoScaling(CHook,X,Y)[a]

VSc(CHook,X,Y)[a]

Có thể trả giá trị “false" với tất cả cả bộ giá trị của CHook, X và Y

VideoDecodeOffset(CHook,Level)

VDO(CHook,Level)

Có thể tr giá trị “false” với tất cả cả bộ giá trị của CHook, X và Y

DownloadableFont(CHook)

DLF(CHook)

Phải trả giá trị "true" cho các giá trị của CHook được hỗ trợ bởi lớp Phông chữ. Phải trả giá trị "false" cho tt cả các giá trị khác của N.

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

Mã hóa dữ liệu nội dung được xác định trong D-Book 5.0 [23], điều 13.5 với các trường hợp ngoại lệ được quy định trong phần này và các phần tiếp theo.

12.3.1. Bảng nội dung

Trong CIEngineProfile1 bảng 13.7 sẽ theo D-Book 5.0 [23] với trường hợp ngoại lệ sau đây:

Bảng 12.4 - Bảng nội dung

Thuộc tính

Các giá trị cho phép

Phông chữ

Xem 12.5.1 "Các phông chữ có thể tải về"

12.3.2. Các định dạng "lưu trữ" của dòng

Trong CIEngineProfile1 không có yêu cầu dành cho các định dạng lưu trữ của dòng, D-Book 5.0 [23] điều 13.5.3.

12.3.3. Đầu vào của người sử dụng

ng dụng CI Plus phải làm nổi bật đầu vào và ưu tiên hiển thị nếu MMI ứng dụng CI Plus cùng tồn tại với bất kỳ công cụ ứng dụng nào khác (ví dụ như chạy đồng thời).

Yêu cầu thực hiện của hồ sơ UK luôn luôn bắt đầu trong thanh ghi 3 của đu vào của người sử dụng trong màn ảnh đầu tiên không được áp dụng đối với các ứng dụng CI Plus.

12.3.4. Các sự kiện của công cụ

Tập tối thiểu các sự kiện của công cụ mà công cụ này hỗ trợ được xác định trong D-Book 5.0 [23] điều 13.8, ngoại trừ các sự kiện của dòng sau đây không được CIEngineProfile1 yêu cầu.

Bảng 12.5 - Các trường hợp ngoại lệ của EventData trong CIEngineProfile1 đối với D-Book 5.0

EventData

Giá tr

Ghi chú

VideoPrefChanged

6

Không bắt buộc

NetworkBootInfo

9

Không bắt buộc

12.3.5. Ánh xạ giao thức và kết nối ngoài

Ánh xạ giao thức và kết nối ngoài của D-Book 5.0 [23] điều 13,9 với trường hợp ngoại lệ của các hành động của dòng và các sự kiện của dòng không được CIEngineProfile1 yêu cầu.

12.3.6. Các chương trình thường trú

Các chương trình thường trú của D-Book 5.0 [23] điều 13.10 với trường hợp ngoại lệ của các chương trình thường trú sau đây không được CIEngineProfile1 yêu cầu.

Bảng 12.6 - Các trường hợp ngoại lệ của chương trình thường trú của CIEngineProfile1 đi với D-Book 5.0

Chương trình thường trú

Tên

Ghi chú

SI_Tunelndex

Tin

Không bắt buộc

SI_Tunelndexlnfo

TII

Không bắt buộc

GetBootlnfo

GBI

Không bắt buộc

VideoToGraphics

VTG

Không bắt buộc

SetWidescreenAlignment

SWA

Không bắt buộc

SetSubtitleMode

SSM

Không bắt buộc

RequestMPEGDecoder

RMD

Ghi chú: Ch gọi. Xem điều 12.3.6.1

12.3.6.1. RequestMPEGDecoder

Các yêu cầu truy nhập dành riêng bộ giải mã MPEG và màn hình video để hiển thị I-frame. Bộ giải mã MPEG này phải sẵn có khi không có môi trường ứng dụng khác đang hoạt động.

Tóm tắt RMD (Kết quả)

Các đối số

vào/ra/

vào-ra

Kiểu

Tên

Diễn giải

Vào

GenericBool

Yêu cầu

Nếu 'true' thì ứng dụng MHEG đang yêu cầu sử dụng dành riêng bộ giải mã MPEG và màn hình video.

Nếu 'false' nó giải phóng bộ giải mã này.

ra

GenericBool

Kết quả

Nếu yêu cầu là ‘true' thì:

• Nếu kết quả là ‘true' thì các I-frame có thể được sử dụng và phải duy trì có sẵn cho tới khi thoát khỏi ứng dụng này, một ứng dụng mới bắt đầu (xem D-Book 5.0 [23] điều 13.10.12) hoặc RequestMPEGDecoder được gọi ra lại bằng yêu cầu = false'.

• Nếu kết quả là ‘false’ thì bộ giải mã MPEG là không có sẵn và các I-frame có thể không được sử dụng.

Nếu yêu cầu là false' thì:

• Kết quả phải là 'false', bộ giải mã MPEG là không có sẵn và các I-frame có thể không được sử dụng.

Mô tả

Nếu ứng dụng CI Plus yêu cầu dừng dòng truyền tải và hiển thị một I-frame thì trước tiên nó phải được cho phép sử dụng bộ giải mã MPEG. Khi ứng dụng này đã kết thúc với bộ giải mã MPEG này, nó có thể giải phóng bộ gii mã bằng cách gọi RequestMPEGDecoder với yêu cầu = 'false' tuy nhiên ứng dụng này đã phải loại bỏ bất kỳ các I-frame trên màn hình và khởi tạo lại dòng với các thành phần mặc định nếu không kết quả sẽ không xác định.

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

Màn hình đồ họa được sử dụng để trình bày tất cả các hình ảnh có thể nhìn thy, ngoại trừ các MPEG I-frame. Trình đơn ứng dụng CI này phải có một vùng đồ họa 720x576 pixel. Màn hình đồ họa này phải phù hợp với độ phân giải và khuôn dạng hình ảnh hiện tại. Trường hợp video có độ nét cao thì màn hình đồ họa phải bị thu nhỏ để phù hợp với độ phân giải và khuôn dạng hiện tại.

Màn hình đồ họa CI Plus phải ở trên (các) màn hình video và bt kỳ màn hình phụ đề nào. Bất kỳ màn hình trung gian giữa màn hình đồ họa CI Plus và các màn hình video (và phụ đề) có thể tùy chọn bị tắt hoặc làm trong suốt, tức là trong một môi trường ứng dụng, màn hình đồ họa ứng dụng có thể được hiển thị nếu màn hình ứng dụng CI Plus là trong suốt.

Việc trình bày không gian màu sắc và bảng màu tối thiểu được D-Book 5.0 [23], điều 14 xác định, truecolour với số bit tối thiểu là 16 bit được khuyến nghị thực hiện.

12.4.1. Lineart và Dynamic Lineart

Lineart và Dynamic Lineart không được CIEngineProfile1 yêu cầu, theo quy định tại D-Book 5.0 [23], điều 14.5.

12.4.2. Các PNG bitmap

Các PNG bitmap phải tuân thủ D-Book 5.0 [23], điều 14.7.

12.4.3. MPEG Stills

MPEG stills hoặc I-frame phải tuân thủ D-Book 5.0 [23], điều 14.8.

12.4.4. Đầu vào của người sử dụng

Đầu vào của người sử dụng được xác định trong D-Book 5.0 [23], điều 13.6. Một ứng dụng được CI Plus khởi tạo có thể bắt đầu trong bất kỳ nhóm thanh ghi nào bao gồm các nhóm thanh ghi 5.

12.4.5. Mẫu đồ họa độ nét cao.

Thiết bị thu độ nét cao (tức là các thiết bị thu có khả năng giải mã và trình bày hình ảnh có độ phân giải hình ảnh HD) phải tuân thủ mẫu đồ họa công cụ được quy định tại điều 12.4 và 12.4.1 đến 12.4.4 với các trường hợp ngoại lệ theo quy định của HDGraphicsPlaneExtension và HDVideoExtension được quy định tại ETSI MHEG [38] điều 12.11 và các mục có liên quan.

12.4.5.1. Khả năng phát hiện

Các ứng dụng CI Plus phải có khả năng xác định khả năng đồ họa của thiết bị thu mà chúng được cung cấp. Máy chủ hỗ trợ mẫu đồ họa HD phải hỗ trợ tính năng "HDExtension" ("HDE") GetEngineSupport được định nghĩa trong ETSI MHEG [38] điều 11.4.1.

12.5. Ký tự của công cụ

CIEngineProfile1 phải tuân thủ hoàn toàn D-Book 5.0 [23], điều 15, ngoại trừ các trường hợp sau đây. Các mục sau đây thay thế điều 15.3.1 và 15.3.1.1 trong D-Book 5.0.

Danh mục ký tự của CIEngineProfile1 tối thiểu phải là danh mục ký tự của UKEngineProfile1 khi sử dụng phông chữ cư trú. ng dụng MHEG có thể sử dụng các ký tự khác có sẵn trong bộ ký tự thay thế sau khi lần đầu tiên xác nhận sự có mặt của bộ ký tự này trong rec://font/xxx, trong đó XXX là bộ ký tự được yêu cầu.

CIEngineProfile1 có một lớp thuộc tính của phông chữ là rec://font/CI1.

Các phông chữ được tải về có thể có một danh mục ký tự rộng hơn và tất cả các ký tự trong phông chữ được tải về phải được hỗ trợ.

12.5.1. Các phông chữ có thể tải về

Các thiết bị thu có thể tùy chọn hỗ trợ phông chữ có thể tải về sử dụng lớp phông chữ MHEG-5. Việc hỗ trợ được chỉ ra bằng trả lời đồng ý đối với DownloadableFont để xác nhận nội dung được hỗ trợ. Chỉ các phông chữ của thiết bị thu có thể được tham chiếu theo tên, các phông chữ được tải về phải được tham chiếu theo đối tượng phông chữ MHEG-5. Thiết bị thu phải hỗ trợ tất cả các ký tự trong một phông chữ được tải về và sẽ không bị giới hạn bởi hồ sơ công cụ của một quốc gia cụ thể. Tập các ký tự được hỗ trợ trong bất kỳ tập tin phông chữ được nhúng trong thiết bị thu có thể bị giới hạn trong một tập các ký tự của một quốc gia cụ thể.

Thiết bị thu hỗ trợ các phông chữ có thể ti về tối thiểu phải dành 256K byte bộ nhớ cho các phông chữ được tự động nạp. Các phông chữ châu Á, như Trung Quốc, yêu cầu thiết bị thu dành bộ nhớ nhiều hơn đáng kể.

Các thiết bị thu được CI Plus cho phép triển khai tại các khu vực này phải xác định yêu cầu CI Plus về bộ nhớ dựa trên các yêu cầu truyền hình của các khu vực địa phương.

Trường hợp các phông chữ có thể tải về được máy chủ hỗ trợ thì chỉ yêu cầu máy chủ hỗ trợ việc tải về của một phông chữ duy nhất. Máy chủ có thể tùy chọn hỗ trợ nhiều phông chữ có thể tải về.

12.5.1.1. Các phông chữ OpenType

Giá trị của Chook là 10 được quy định dành cho phông chữ OpenType® phù hợp phiên bản 1.4 của bản quy định kỹ thuật OpenType với TrueType ™ được công bố trên các trang web sau đây:

<http://www.microsoft.com/typography/otspec/default.htm>

<http://partners.adobe.com/asn/tech/type/opentype/index.jsp>

Tập phông chữ TrueType không được hỗ trợ trong hồ sơ này. Một tập tin phông chữ chứa một phông chữ duy nhất. Phông chữ duy nhất này sẽ được tham chiếu làm kiểu phông chữ mặc định 'đơn giản'. Trường hợp các phông chữ có thể tải về được hỗ trợ thì yêu cầu thiết bị thu hỗ trợ các bng dưới đây:

• Các bảng liên quan đến phông chữ TrueType

• bảng co giãn (định dạng "0" chỉ co giãn chiều ngang).

Việc hỗ trợ các bảng này không phải là bắt buộc mà là tùy chọn.

Đối với các phông chữ OpenType, bảng sau đây xác định các giá trị được sử dụng dành cho các tham số của phông chữ trong D-Book 5.0 [23], điều 15.5.

Bảng 12.7 - Các tham số của phông chữ OpenType

Tên thông số

Lấy được từ

metricsResolution,

outlineResolution

Trường unitsPerEm, được định nghĩa ở bảngFontHeader(head)

advanceWidth,

charSetWidth

Các giá trị advanceWidth, được định nghĩa ở bng Horizontal Metrics ('htmx’). Xem CHÚ THÍCH

xMin, yMin, yMax

được định nghĩa ở bảng Font Header ('head')

Kem

Giá trị, được định nghĩa ở bng Kernng ('kern') table

CHÚ THÍCH: đối với các phông chữ đơn khoảng cách, chỉ có thể định nghĩa một giá trị advanceWidth

12.5.1.2. Trình bày

Khi một đối tượng ký tự tham chiếu một phông chữ được tải về thì đối tượng này phải được trình bày theo quy định tại D-Book 5.0 [23] điều 14.10, "Hình dáng của các đối tượng có thể nhìn thấy trong quá trình phục hồi nội dung" cho đến khi việc tải về phông chữ thành công hoặc việc tải về phông chữ không thành công. Nếu việc tải về phông chữ không thành công thì thiết bị thu phải sử dụng phông chữ mặc định sẵn có của thiết bị thu để thay thế. Khi sử dụng phông chữ mặc định sẵn có của thiết bị thu, đối tượng văn bản này phải được trình bày sử dụng quy tắc dành cho phông chữ đó bao gồm cả danh mục ký tự được thiết bị thu xác định.

12.5.1.3. Phản ứng phòng ngừa

Việc tải về phông chữ có thể thất bại và các ứng dụng có thể yêu cầu các tính năng và đặc điểm không hợp lệ hoặc không được hỗ trợ. Đ xử lý các sự kiện này theo cách có thể dự đoán trước và chắc chắn, thiết bị thu phải thực hiện những biện pháp sau đây:

• Thiết bị thu phải sử dụng phông chữ sẵn có của nó thay thế phông chữ được ti khi

o Phông chữ được yêu cầu không có sẵn

o Xác nhận nội dung không được xác nhận

o Các thuộc tính của phông chữ không hợp lệ

Khi sử dụng phông chữ của thiết bị thu thì phải trình bày hộp văn bản theo phông chữ của thiết bị thu được quy định.

• Kiểu phông chữ được hỗ trợ chỉ là 'đơn giản'. Nếu có quy định bất kỳ kiểu font khác thì phải xử lý như kiểu ‘đơn giản’.

• Nếu kích thước phông chữ được yêu cầu không được phông chữ này hỗ trợ thì phải sử dụng kích thước nhỏ hơn tiếp theo. Nếu phông chữ được yêu cầu nhỏ hơn kích thước phông chữ nhỏ nhất có sẵn thì phải sử dụng kích thước có sẵn này.

12.6. Thời gian sống của ứng dụng CI

Phần này trình bày thời gian sống của ứng dụng. Không được thay đổi D-Book 5.0 [23] điều 16, trừ những thay đổi cụ thể được trình bày trong trong phần này.

12.6.1. Thời gian sống của ứng dụng

Thời gian sống của ứng dụng là phương pháp thông báo ứng dụng CI được khởi tạo hoặc kết thúc.

12.6.1.1. Khởi tạo và kết thúc ứng dụng CI Plus

ng dụng CI Plus dành cho máy chủ CIEngineProfile1 phải được CICAM giới thiệu một cách rõ ràng bng một RequestStart. Máy chủ có thể trả lời bằng một trả lời API busy nếu nó không thể đáp ứng yêu cầu này và CICAM có thể cố thử lại yêu cầu này sau đó.

Các ứng dụng CICAM có thể kết thúc vì một số lý do và điều kiện kết thúc phải được thông báo cho CICAM như sau:

• Chúng thực hiện thao tác "Quit"

• Chúng bị máy chủ chấm dứt vì thay đổi kênh.

• Chúng bị chấm dứt vì mô-đun CI tạo một bản tin RequestStart hoặc AppAbortRequest.

ng dụng CI Plus không thể được tồn tại khi phụ đề hoặc RTGraphics được kích hoạt.

Hệ thống tập tin CI được gắn kết với hoạt động của mô-đun CI. Trạng thái đầu ra hiện tại của video, âm thanh, và tùy chọn bất kỳ ứng dụng khác, phải giữ không đổi. Tùy chọn có thể vô hiệu, phụ đề và ứng dụng này được khởi tạo và sẵn có. Đồ họa của ứng dụng này phải được thu nhỏ/phóng to để phù hợp với độ phân giải màn hình video hiện tại.

12.6.2. Tương tác với mô-đun giao diện chung DVB

Tương tác với mô-đun giao diện chung DVB phải tuân thủ D-Book 5.0 [23], điều 16.11. Phải sử dụng nhãn nhận dạng miền ứng dụng "CIMHEGP1" (0x43494d4845475031) trong bản tin Requeststart để xác định rằng miền ứng dụng được yêu cầu là CIEngineProfile1.

Nhãn nhận dạng miền ứng dụng có thể được tùy chọn thay đổi bằng các đối số xác định các yêu cầu của môi trường ứng dụng CI Plus. Các tùy chọn này được quy định tại phần cuối của nhãn nhận dạng miền ứng dụng được phân cách nhau bằng dấu chấm phẩy (;) tức là <applicationDomainIndentifier> [; <option1>; <option2>;...; <tùy chọn #> ] trong đó các tùy chọn được định nghĩa như sau:

Bảng 12.8 - Các tùy chọn khởi tạo nhãn nhận dạng miền ứng dụng

Tên

Giá trị tùy chọn

Ghi chú

SSM RTGraphics State

SSM=0

Các phụ đề (RT Graphics) phải được tắt trước khi bắt đầu CI Plus Application, các tiêu đề phải được trả lại trạng thái trước đó sau khi chm dứt CI PlusApplication

SSM=1

Các phụ đề (RTGraphics) phải xuất hiện khi được kích hoạt bởi lựa chọn của người sử dụng, nếu CI PlusApplication và các phụ đề không thể cùng tồn tại thì CI PlusApplication không được phép bắt đầu.

SSM=2

Các phụ đề (RTGraphics) phải được tùy chọn để xuất hiện khi được kích hoạt bởi sự lựa chọn của người sử dụng, nếu CI PlusApplication và các phụ đề không thể cùng tồn tại thì phụ đề phải bị tắt và CI PlusApplication phải bắt đầu. Tại những chỗ mà phụ đề tạm thời ghi đè lên lựa chọn của người sử dụng và được tắt thì trạng thái phụ đề đang tồn tại phải được khôi phục khi kết thúc ứng dụng. Tùy chọn này là trạng thái mặc định phải được giả thiết khi tùy chọn SSM bị bỏ ra khỏi bộ xác định miền ứng dụng.

12.6.2.1. Hồ Sơ truyền hình MHEG

Trường hợp hồ sơ truyền hình của một quốc gia nhất định hỗ trợ một môi trường MHEG truyền hình thì có thể thiết kế CICAM theo một hồ sơ truyền hình cụ thể và khởi tạo với nhãn nhận dạng miền ứng dụng của hồ sơ này mà không phải là hồ sơ CI. Xem D-Book 5.0 [23], điều 16.11.3.2. Thời gian sống của ứng dụng đối với hồ sơ truyền hình này có thể là quan trọng và có thể cho phép:

• Mô-đun CI giới thiệu một ứng dụng CI

• Một ứng dụng truyền hình tùy chọn giới thiệu một ứng dụng CI.

Tức là, CICAM có thể sử dụng hồ sơ truyền hình MHEG chứ không phải là môi trường ứng dụng CI Plus dành cho một ứng dụng CI Plus của nhà điều hành cụ thể. CICAM có thể tiếp tục sử dụng MMI ứng dụng CI Plus dành cho các trình đơn và bản tin của CICAM cụ thể.

12.6.2.2. H Sơ truyền hình MHP

Trường hợp hồ sơ này hỗ trợ MHP thì MMI ứng dụng CI Plus phải được ưu tiên hơn môi trường ứng dụng MHP này và phải tập trung đầu vào. Màn hình đồ họa MHP có thể bị tạm thời loại bỏ hoặc MMI ứng dụng CI Plus phải xuất hiện ở phía trước nó. Khi MMI ứng dụng CI Plus là một phần mở rộng của OSD riêng thì việc tồn tại đầu ra CI Plus trên màn hình đồ họa riêng của máy chủ để thay thế cho giao diện đồ họa riêng (OSD) là có thể chp nhận.

12.6.2.3. Yêu cầu và xác nhận tập tin

Độ dài tối đa của một FileNameLeng yêu cầu hoặc xác nhận tập tin không được quy định nhưng phải phù hợp với tài nguyên bộ nhớ trình duyệt CI Plus.

12.6.2.4. Lưu trữ thường trực

Công cụ CI Plus phải cung cấp tối thiểu 1.024 byte dữ liệu theo D-Book [23] điều 16.7. Lưu trữ thường trực có thể được thực hiện trong bộ nhớ dễ thay đổi.

12.6.3. Mu tài nguyên máy chủ

Theo D-Book 5.0 [23] các điều 16.8 và 16.9 với những giới hạn sau đây.

12.6.3.1. Tài nguyên bộ nhớ

Thiết bị thu phải tối thiểu cung cấp 512 Kbyte RAM dành cho ứng dụng CI Plus này. Trong trường hợp công cụ này hỗ trợ đồ họa độ nét cao thì thiết bị thu phải tối thiểu cung cấp 1 Mbyte RAM dành cho ứng dụng CI Plus này. Trong trường hợp công cụ hỗ trợ các phông chữ có thể tải về thì thiết bị thu phải cung cấp thêm một 256 Kbyte RAM để xử lý phông chữ theo quy định tại 12.5.1.

12.6.3.2. Hành vi quay lại liên kết

Công cụ CI Plus phải cho phép ít nhất 128 hoạt động đồng thời và ít nhất là 1024 hoạt động thành phần chờ xử lý.

12.6.3.3. Tính và độ chi tiết của thời gian

Công cụ CI Plus phải cho phép ít nhất 4 đồng hồ MHEG-5 có thể hoạt động đồng thời với độ chính xác +/- 10 ms. Khi có nhiều hơn 4 đồng hồ đang hoạt động thì độ chính xác có thể bị suy giảm theo một cách cụ thể.

Thiết bị thu phải hỗ trợ khoảng thời gian của đồng hồ hoạt động lên đến ít nhất 1 giờ.

12.6.3.4. Xếp chồng ứng dụng

Xếp chồng ứng dụng theo điều 16.9 của D-Book 5.0 ngoại trừ việc xếp chồng ứng dụng phải có khả năng giữ tham chiếu đến ít nhất 5 ứng dụng.

12.7. Ánh xạ tên

12.7.1. Các tên trong máy chủ

Các tên trong một máy chủ CIEngineProfile1 bao gồm:

Bảng 12.9 - Các tên trong máy chủ hồ sơ CI

Tên

Ghi chú

rec://font/CI1

Nhận diện phông chữ được dùng kè, các tên phông chữ khác có thể tồn tại nhưng không bị bắt buộc bởi CIEngineProfile1.

Phông chữ này được định nghĩa cho Tây Âu và phải giống hệt UK-DTTUK1”

ram://<name>

Không gian tên cho việc lưu trữ lâu.

12.7.2. Ánh xạ không gian tên

Khi một ứng dụng được bắt đầu thì một phiên MMI với một Mô-đun CI DVB đã được thiết lập và hệ thống tập tin CI có thể được sử dụng để lấy các đối tượng của tập tin chứa các đối tượng CIEngineProfile1 MHEG-5 hoặc nội dung dữ liệu như văn bản và các bitmap.

Các tập tin đối tượng MHEG là màn ảnh, ứng dụng hoặc dữ liệu nội dung của một đối tượng thành phần, trong đó mỗi màn ảnh, đối tượng ứng dụng hoặc dữ liệu nội dung được lưu trữ trong một tập tin riêng biệt.

12.7.3. Tham chiếu đối tượng MHEG-5

Các quy tắc tham chiếu đối tượng MHEG-5 của D-Book 5.0 [23] điều 18.3.1 được áp dụng ngoại trừ các đối tượng DSM-CC.

12.7.4. Các quy tắc ánh xạ dành cho GroupIdentifier và ContentReference

Các quy tắc ánh xạ dành cho GroupIdentifier và ContentReference của D-Book 5.0 [23] điều 18.3.2 được áp dụng với những lưu ý sau đây:

12.7.4.1. Nhạy cảm loại chữ

Hệ thống tập tin CI cung cấp các tên tập tin nhạy cảm loại chữ.

12.7.4.2. Cu trúc tham chiếu tập tin

“DSM:" và “~” (viết tắt của "DSM:") không được yêu cầu trong CIEngineProfile1. Hệ thống tập tin gốc CI được tham chiếu là CI:”.

12.7.4.3. Nhớ đệm

Hành vi nhớ đệm mặc định của nội dung "CI:" là "việc nhớ đệm không được phép" (CCPO) và theo mặc định tất cả các tham chiếu tập tin được yêu cầu thông qua giao diện CI. Việc hỗ trợ ContentCachPriority (CCP) với hệ thống tập tin CI là không bắt buộc đối với CIEngineProfile1.

Máy chủ có thể tùy chọn thực hiện việc nhớ đệm hệ thống tập tin CI và có thể phân tích ContentCachePriority và GroupCachingPriority này và phải được sử dụng tuân thủ theo D-Book [23], Bất kỳ máy chủ thực hiện cơ chế nhớ đệm phải hỗ trợ hành vi nhớ đệm tương tự như được quy định trong hồ sơ băng chuyền đối tượng MHEG, ngoại trừ những từ "dòng truyền hình" và "băng chuyền truyền hình" được thay thế bằng "hệ thống tập tin CI". Có thể thực hiện nhớ đệm bằng cách sử dụng tài nguyên MMI ứng dụng v1 hoặc v2 cho hiệu quả cao hơn (xem 14.5).

Ưu tiên nhớ đệm nhóm hay nội dụng phải được phân tích và áp dụng cho hệ thống tập tin CI này theo Bảng 12.10.

Bảng 12.10 - Hành vi nhớ đệm của CICAM

Ưu tiên nhớ đệm

Ý nghĩa

Phương pháp truy tìm nhớ đệm

Các giá trị chẵn (trừ không)

Các giá trị chẵn khác không của mức ưu tiên lưu trữ (2, 4, 6, v.v.) cho biết rằng đối tượng này có thể được ly về từ bộ lưu trữ cục bộ mà không cần tham chiếu đến CICAM. Giá trị này cho biết dữ liệu là tĩnh và giá trị càng cao thì dữ liệu này càng có ích để lưu trữ.

Bất k nội dung nào cần được lưu trữ lâu thông qua các phiên MHEG phải được xem như không có ý nghĩa khi bắt đầu một phiên MHEG mới và phải được lấy lại sử dụng RequestType = FileHash hoặc RequestType = File.

Sử dụng nội dung được lưu trữ cục bộ và không cũ (hoặc không có ý nghĩa)

Các giá trị lẻ

Các giá trị chẵn khác không của mức ưu tiên lưu trữ (2, 4, 6, v.v.) cho biết rằng máy chủ phải kiểm chứng nội dung là mới trước khi sử dụng dữ liệu từ bộ lưu trữ. Giá trị càng cao có nghĩa dữ liệu càng có ích để lưu trữ.

CHÚ THÍCH: Để kiểm chứng rằng nội dung là mới thì một yêu cầu File phải được gửi tới CICAM, tức là bộ lưu trữ chỉ có ích cho các máy chủ có hỗ trợ các yêu cầu loại FileHash.

RequestType=FileHash hoặc RequestType=File

Không

Đây là giá trị mặc định khi không có bộ lưu trữ CICAM.

Không được phép lưu trữ nội dung này, các bản sao đã được lưu trữ của dữ liệu này, nếu có, phải được hủy và phải được lấy lại một cách rõ ràng từ CICAM với RequestType=File.

RequestType=FileHash không được sử dụng cho CPP0

RequestType=File

12.8. Các phần mở rộng VOD

MMI ứng dụng mở rộng các tính năng của công cụ này để hỗ trợ các yêu cầu của tiêu chuẩn này và bao gồm các chương trình thường trú bổ sung để hỗ trợ các ứng dụng VOD. Cung cấp VOD sử dụng kiểm soát máy chủ v2 và một ứng dụng VOD yêu cầu một cơ chế lấy mã khóa nâng cao và việc kiểm soát n màn hình đồ họa là các phần mở rộng VOD và là yêu cầu đối với tất cả các máy chủ thực hiện theo tiêu chuẩn này (CI Plus).

12.8.1. Các chương trình thường trú

Các chương trình thường trú phải bao gồm thêm các chương trình được liệt kê trong Bảng 12.11.

Bảng 12.11 - Các phần mở rộng chương trình thường trú VOD của CI Plus

Chương trình thường trú

Tên

Ghi chú

TestlnputMask

TIM

Quản lý mã khóa VOD - Sách trắng DTG

SuppressMHEGGraphics

SMG

Điều khiển hiện thị VOD-CI Plusv1.3 Extension

Một ứng dụng có thể kiểm tra sự tồn tại của các phần mở rộng VOD bằng cách kiểm tra sự tồn tại của chương trình thường trú SMG này.

12.8.1.1. Mặt nạ đầu vào kiểm tra

Việc xử lý mã khóa đầu vào phải được mở rộng với các phần mở rộng mặt nạ đầu vào để cung cấp MMI ứng dụng khả năng truy nhập các mã khóa kiểm soát video, điều này được trình bày chi tiết trong tài liệu "DTG MHEG spec Group White Paper: MHEG InputMaskExtensions".

Phải cung cấp InputEventMask trong lớp màn ảnh.

Phải hỗ trợ SetlnputMask (NewInputMask) của hành động thành phần.

12.8.1.2. Ngăn chặn đồ họa MHEG

Chương trình thường trú SuppressMHEGGraphics cung cấp việc kiểm soát chuyn đổi giữa các màn hình phụ đề và đồ họa ứng dụng trên các máy chủ chỉ hỗ trợ một màn hình đồ họa duy nhất. Chương trình thường trú này cho phép phụ đề tn tại trong khi một ứng dụng tiếp tục được thực hiện, ngoài ra cũng cho phép phụ đề bị ngăn chặn và đồ họa ứng dụng được khôi phục đối với môi trường ứng dụng này. Gọi chương trình cư trú trên một máy chủ có hỗ trợ hiển thị đồng thời phụ đề và đồ họa MHEG, không đảm bảo rằng màn hình đồ họa này bị loại bỏ và việc loại bỏ tt c các đối tượng nhìn thy được là trách nhiệm của ứng dụng này.

Tóm tắt SMG (GraphicsState)

Đối số

Vào/ra

Kiểu

Tên

Diễn giải

Vào

GenericBool

GraphicsState

Nếu đúng thì MMI ứng dụng này đã loại bỏ màn hình đồ họa và phụ đề có thể được hiển thị khi được kích hoạt. Màn hình đồ họa có thể bị ngăn chặn.

Nếu sai thì MMI ứng dụng này yêu cầu màn hình đồ họa và phụ đề phải bị dừng lại và việc kiểm soát màn hình đồ họa phải trả về cho MMI ứng dụng vào cuối cuộc gọi chương trình thường trú.

Mô tả

Khi máy chủ hỗ trợ hiển thị đồng thời MMI ứng dụng và phụ đề thì chương trình thường trú này không được có hiệu lực. Không được yêu cầu MMI ứng dụng n các đối tượng đồ họa và các đối tượng đồ họa có thể vẫn còn nhìn thấy được.

Khi máy chủ không hỗ trợ hiển thị đồng thời MMI ứng dụng và phụ đề thì trường hợp MMI ứng dụng đã được khởi tạo với SSM = 2 và MMI ứng dụng được hiển thị thì màn hình đồ họa phải bị ngắt kết nối khỏi MMI ứng dụng và phải được sử dụng để hiển thị phụ đề, khi phụ đề được kích hoạt và tn tại trong dòng truyền tải này. ng dụng có thể mất màn hình đồ họa khi SuppressMHEGGraphics (đúng) được gọi ngay cả khi phụ đề không được kích hoạt. Khi SupressMHEGGraphics (sai) được gọi thì phụ đề phải bị dừng lại và màn hình đồ họa phải được tr về cho ứng dụng.

Chương trình thường trú có thể được một ứng dụng sử dụng như sau:

1. ng dụng MMI được khởi tạo với SSM = 2 trên một thiết bị thu không hỗ trợ hiển thị đồng thời ứng dụng và phụ đề. Người sử dụng đã kích hoạt phụ đề và phụ đề có mặt trong dòng truyền tải này.

2. ng dụng được bắt đầu và phụ đề bị ngăn chặn.

3. Người sử dụng chuyển hướng thông qua ứng dụng này và lựa chọn một tùy chọn không yêu cầu đồ họa (tức là màn hình được lấp đầy rõ ràng), ứng dụng này ẩn tất cả các thành phần đồ họa có thể nhìn thấy và gọi SuppressMHEGGraphics (đúng).

4. Màn hình đồ họa bị ngắt kết nối khỏi môi trường ứng dụng này và phụ đề được trình bày. Có thể sẽ có một khoảng thời gian trễ ngắn trong trình bày phụ đề khi khởi tạo bộ giải mã phụ đề.

5. ng dụng này tiếp tục nhận được mã khóa được nhập vào và có thể liên kết và tải các tập tin từ CICAM

6. Người sử dụng thực hiện một hành động yêu cầu hin thị ứng dụng này. ứng dụng này gọi SuppressMHEGGraphics (sai). Khi chương trình thường trú này trở lại, phụ đề bị ẩn và màn hình đồ họa được khôi phục đối với ứng dụng này. Ứng dụng này có thể làm cho các thành phần đồ họa có thể nhìn thấy và chúng phải xuất hiện.

Các sản phẩm lỗi thời sẽ không hỗ trợ chương trình thường trú SuppressMHEGGraphics 0 và phụ đề sẽ vẫn bị vô hiệu trong khi ứng dụng này đang chạy.

12.9. Hướng dẫn và quy định thực hiện MHEG-5

Các quy tắc thực hiện này được quy định tại D-Book 5.0 [23] điều 19 được áp dụng nhưng phải tuân thủ các giới hạn của CI Plus, tức là các ứng dụng bị giới hạn với 512 Kbyte. Lưu ý rằng các ứng dụng HD có thể lớn hơn nhưng ứng dụng này phải xác định rằng công cụ này hỗ trợ HD trước khi cố gắng tăng kích thước ứng dụng lên đến 1 Mbyte.

Các ứng dụng CI Plus phải được thực hiện với lưu ý rằng chúng có thể được triển khai trong các môi trường SD hay HD nơi màn hình đồ họa ứng dụng này phải phụ thuộc vào việc phóng to thu nhỏ.

CICAM phải xem xét trạng thái phụ đề (RTGraphics) khi khởi tạo một ứng dụng CI Plus. Đối với một số máy chủ, việc tồn tại cùng một lúc đối với ứng dụng CI Plus và phụ đề có thể là không được, trong trường hợp này phụ đề phải được ưu tiên khi CICAM cố gắng cài đặt một ứng dụng CI Plus nền, cho phép người sử dụng duy trì phụ đề.

Các ứng dụng phải đảm bảo rằng việc hỗ trợ phông chữ có thể tải về tồn tại trên máy chủ khi được sử dụng. Các phông chữ OpenType sử dụng các bảng tùy chọn nên được các người tạo ra ứng dụng tránh vì các kết quả này sẽ thay đổi theo thiết bị thu cụ thể. ng dụng này chỉ phải sử dụng một phông chữ có thể tải về duy nhất.

Việc tải về phông chữ có thể tht bại. Nếu điều này xảy ra thì văn bản có sử dụng các ký tự không có trong bộ ký tự mặc định của thiết bị thu sẽ được trả lại không chính xác. ng dụng này cần phòng ngừa điều này, ví dụ như bằng cách giám sát sự kiện ContentAvailable từ đối tưng phông chữ trước khi kích hoạt đối tượng văn bản.

Văn bản phải luôn được trả lại trái sang phải, từ trên xuống dưới, ở những khu vực, dòng văn bản từ phải sang trái thì công cụ ứng dụng CI Plus sẽ không bao gói từ chính xác. ng dụng MHEG có thể được thực hiện điều chnh và việc điều chỉnh văn bản này nên chèn ký tự ngắt dòng tại các đim thích hợp để đảm bảo dòng văn bản và trình bày chính xác.

Các ứng dụng CI Plus có thể tồn tại trong các môi trường mà chúng có thể cạnh tranh với các môi trường ứng dụng khác để sử dụng bộ giải mã MPEG vì khi sử dụng các I-frame là mong muốn đối với ứng dụng CI Plus mà chúng có thể không luôn luôn có sẵn. Điều này không có ý để ứng dụng CI Plus can thiệp dòng truyền tải. Người tạo ra ứng dụng này phải lưu ý để đảm bảo các kết quả có thể dự đoán trước, để đảm bảo điều này, các ứng dụng CI Plus phải thực hiện theo các quy tắc sau đây:

ng dụng này luôn luôn phải bắt đầu với một dòng hoạt động có một nội dung gốc thuộc "rec://svc/cur". Đối tượng dòng này phải ghép đối tượng âm thanh và một đối tượng video. Cả đối tượng âm thanh và video phải có một thẻ thành phần là -1. Đối tượng video này phải có một orignalBoxSize rộng 720 và cao 576. Đối tượng video này phải có một XYPosition là 0,0.

ng dụng này không được quy định khuôn dạng màn ảnh.

ng dụng này không được thay đổi vị trí, mức phóng to thu nhỏ hoặc độ lệch bù giải mã của hình ảnh trực tiếp, tuy nhiên ứng dụng này có thể thay đổi vị trí, mức phóng to thu nhỏ và độ lệch bù giải mã của các I-frame.

• Trước khi dừng đối tượng dòng này trình bày dòng truyền tải, ứng dụng CI Plus phải được cho phép của chương trình thường trú RequestMPEGDecoder (điều 12.3.5.1). Khi sự cho phép đã được cp, nó vẫn được cp trong suốt thời gian của chương trình thường trú theo quy định tại D-Book 5.0 điều 13.01.12 hoặc cho đến khi ứng dụng CI Plus giải phóng sự cho phép này.

• Các ứng dụng không nên yêu cu sử dụng bộ giải mã MPEG nhiều hơn mức cần thiết. Nếu RequestMPEGDecoderhas được trả về ‘sai’ thì nó có kh năng tr về ‘sai’ nếu nó được gọi lại.

• Khi đối tượng dòng truyền tải đã bị dừng thì một I-frame có thể được trình bày.

ng dụng CI Plus có thể từ bỏ sự cho phép sử dụng bộ giải mã MPEG, trước khi làm như vậy, ứng dụng CI Plus phải đảm bảo bộ giải mã MPEG trong trạng thái tương tự như trước khi sự cho phép sử dụng bộ giải mã MPEG đã được cấp. Phải loại bỏ bất kỳ I-frame nào khỏi màn hình và một đối tượng dòng dành cho dòng truyền tải được khởi tạo.

Bất kỳ ứng dụng CI Plus nào không tuân theo các quy tắc này có nguy cơ có hành vi không dự đoán được.

Khi màn ảnh đầu tiên của ứng dụng có thể bắt đầu trong bất kỳ chế độ thanh ghi đầu vào hợp lệ thì nó nên bắt đầu trong thanh ghi đầu vào 3. Bt đầu trong thanh ghi đầu vào 5, ví dụ, có ảnh hưởng nói chung không mong muốn là hạn chế khả năng của người sử dụng thay đổi kênh.

Người tạo ra ứng dụng nên xem xét điều 14,7 của D-Book 5.0 khi tạo các PNG. Loại bỏ những phần không sử dụng từ một PNG và giảm độ sâu màu có thể tác động đáng kể lên kích thước tập tin và thời gian tải ứng dụng.

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

13.1. MMI cấp thấp

MMI cấp thấp là tùy chọn và không bắt buộc đối với CI Plus.

13.2. MMI cấp cao

Tiêu chuẩn này không làm thay đổi EN 50221 [7] điều 8.6, MMI cấp cao, nhưng mở rộng với một yêu cầu bổ sung:

• Máy chủ phải có thể hiển thị 40 ký tự và 5 dòng ngoài của tiêu đề, phụ đề và dòng dưới cùng.

Hình 13.1 - Trình bày MMI cấp cao

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

Bảng dưới đây chỉ ra các khả năng MMI của máy chủ và CICAM trong các hồ sơ DVB CI và CI Plus.

Bảng 13.1 - Tài nguyên MMI của máy chủ/CICAM DVB-CI/CI Plus

 

Máy chủ

DVB-CI

CI Plus

CICAM

DVB-CI

- MMI cấp cao: Bắt buộc

- MMI cấp thấp: Tùy chọn

- MMI cấp cao: Bắt buộc

- MMI ứng dụng "CI Plusbrowser":Tùy chọn

CI Plus

- MMI cấp cao: Bắt buộc

- MMI cấp cao: Bắt buộc

- MMI ứng dụng "CI Plusbrowser": Bắt buộc

13.4. Trình đơn CICAM

Khuyến nghị sau đây được thực hiện đối với trình đơn CICAM trên máy chủ.

• Số lượng tối đa của các cấp để truy nhập vào menu CICAM là nhỏ hơn 3.

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

14.1. Tài nguyên truyền tốc độ thấp phiên bản 3

Phiên bản 3 của truyền tốc độ thấp thay đổi các bản tin và giao thức để tăng thông lượng dữ liệu.

• Kích thước tối đa của các bộ đệm gửi và nhận được tăng lên 2048 byte.

• Máy chủ và CICAM sử dụng một nhóm bộ đệm cố định có 16 bộ đệm theo mỗi hướng.

• Xác nhận nhiều bộ đệm.

• Thông báo tính sẵn có của nhiều bộ đệm không được xác nhận.

Tốc độ bit tối thiểu được hỗ trợ phải là 1 Mbps.

14.1.1. Sửa đổl comms_cmd

Những thay đổi trong comms_cmd () APDU có liên quan đến lệnh Set_Params. Buffer_size nó hiện tại đã được mã hóa như một giá trị 16 bit. buffer_size và reception_timeout đều có các giá trị mặc định.

CICAM chỉ phải gửi lệnh Set_Params khi phía mạng không được kết nối hoặc khi một kết nối mạng được thiết lập và dữ liệu tải chưa được truyền.

Bảng 14.1 - Mã hóa đối tượng Comms Cmd

buffer_size: Kích thước tối đa, tính theo byte, của các bộ đệm được trao đổi theo cả hai hướng. Giá trị tối đa của buffer_size là 2048. Giá trị mặc định dành cho kích thước bộ đệm, khi lệnh Set_Params không được gửi, là 254 byte.

reception_timeout: Một giá trị thời gian chờ nhận, tính theo bội s của 10 ms. Nếu máy chủ đã nhận được một hoặc nhiều byte trong bộ đệm hiện tại và thời gian chờ này đã trôi qua mà không có thêm byte nhận được, thì bộ đệm này được gửi đến CICAM. Nếu bộ đệm đầy tới giới hạn được tham số buffer_size thiết lập mà không có thời gian chờ thì bộ đệm này được gửi ngay lập tức. Giá trị mặc định dành cho reception_timeout là 10, tức là 100 ms. reception_timeout 0 là không hợp lệ và không được sử dụng.

14.1.2. Sửa đổi comms_reply

Với phiên bản 3 của tài nguyên LSC, máy chủ không được xác nhận tính sẵn có của một bộ đệm trước khi gửi nó đến CICAM. Do đó, máy chủ không bao giờ được gửi comms_reply () với comms_reply_id được thiết lập là 05 (comms_reply_id của Get_Next_Buffer_Ack trước đó).

Bảng comms_reply_id được quy định như sau:

Bảng 14.2 - comms_reply_id

comms_reply_id

id_value

Connect_Ack

0x01

Disconnect_Ack

0x02

Set_Params_Ack

0x03

Status_Reply

0x04

Dự phòng

0x05

Send_Ack

0x06

Dự phòng

Các giá trị khác

Cú pháp của bản tin comms_reply () là không đổi so với Bảng 54 trong EN 50221 [7].Zero (0x00) là giá trị trả về OK tiêu chuẩn, 0xff là lỗi không xác định. Xem Phụ lục E.14.

Giá trị trả về comms_reply () dành cho Set_Params_Ack là 0 khi máy chủ chấp nhận kích thước bộ đệm được CICAM yêu cầu hoặc 0xfe (bộ đệm quá lớn) khi máy chủ không thể xử lý các bộ đệm gửi và nhận có kích thước được CICAM yêu cầu này. Trong trường hợp này, kích thước bộ đệm và thời gian chờ vẫn không thay đổi và CICAM có thể gửi lại một lệnh Set_Params với một kích thước bộ đệm nhỏ hơn.

Set_Params_Ack phải trả về 0xff khi CICAM yêu cầu reception_timeout là 0. reception_timeout trước đó không được thay đổi trong trường hợp này. Set_Params_Ack phải trả về 0xff để trả lời lệnh Set_Params đã được gửi sau khi kết nối mạng được thiết lập và dữ liệu đã được truyền.

14.1.3. Kiểm soát dòng của CICAM

Với phiên bản 3 của tài nguyên truyền tốc độ thấp, CICAM sử dụng một số bộ đệm cố định là 16 bộ đệm.

Tính sẵn có của tập các bộ đệm liên tiếp được máy chủ chỉ ra bằng cách gửi Get_Next_Buffer với

comm_phase_id được thiết lập theo nhãn nhận dạng của bộ đệm cuối cùng trong tập các bộ đệm. Tập các bộ đệm được định nghĩa là Get_Next_Buffer comm_phase_id cuối cùng cộng với một (mô đun 16), hoặc không khi không có Get_Next_Buffer đã được gửi t khi mở phiên hoặc kết nối kênh, đến Get_Next_Buffer comm_phase_id hiện tại, bao gồm cả hai Get_Next_Buffer comm_phase_id.

Khi dữ liệu nhận được có sẵn từ kênh này, máy chủ phải sử dụng comms_rcv APDU với comm_phase_id được thiết lập theo comms_rcv APDU comm_phase_id cuối cùng cộng với một (mô đun 16), hoặc không khi không có comms_rcv APDU đã được gửi từ khi mở phiên hoặc kết nối kênh. Bộ đệm này tương ứng với comm_phase_id được xem là không còn có sẵn cho đến khi CICAM gửi Get_Next_Buffer APDU mô tả một tập các bộ đệm trong đó bao gồm cả bộ đệm đã đ cập.

Máy chủ phải dừng gửi comms_rcv APDU khi tất cả các bộ đệm có sẵn đã được sử dụng. Máy chủ phải đợi cho đến khi CICAM chỉ ra tính sẵn có của một tập các bộ đệm mi trước khi gửi một APDU comms_rcv, nếu được yêu cầu.

Hình 14.1 - Kiểm soát dòng của CICAM

Bảng 14.3 dưới đây chỉ ra tính sẵn có của mỗi bộ đệm trong số 16 bộ đệm, sau một số bước của hình 14.1 trên:

Bảng 14.3 - Tính sẵn có của bộ đệm trong hình 14.1

Buffer Id

Bước

[1]

[3]

[5]

[10]

[12]

[14]

[16]

[18]

[20]

0

O

X

O

O

O

O

O

O

O

1

O

O

O

X

O

O

O

O

O

2

O

O

O

X

X

O

O

O

O

3

O

O

O

X

X

X

X

O

O

4

O

O

O

X

X

X

X

X

O

5

O

O

O

O

O

O

X

X

O

6

O

O

O

O

O

O

O

O

O

7

O

O

O

O

O

O

O

O

O

8

O

O

O

O

O

O

O

O

O

9

O

O

O

O

O

O

O

O

O

10

O

O

O

O

O

O

O

O

O

11

O

O

O

O

O

O

O

O

O

12

O

O

O

O

O

O

O

O

O

13

O

O

O

O

O

O

O

O

O

14

O

O

O

O

O

O

O

O

O

15

O

O

O

O

O

O

O

O

O

"O" có nghĩa là bộ đệm có sẵn dành cho máy chủ

"X" có nghĩa là bộ đệm không có sẵn dành cho máy chủ

Bộ đệm có sn tiếp theo được máy chủ sử dụng để nhận dữ liệu được đánh dấu bằng một "O" đậm. Các bước trong hình 14.1 được mô tả dưới đây:

1) Sau khi kết nối được thiết lập thành công trên kênh này, CICAM gửi Get_Next_Buffer với comms_phase_id được thiết lập là 15, để chỉ ra cho máy chủ rằng các bộ đệm từ 0 đến 15 thể được lấp đầy

2) Máy chủ nhận dữ liệu trên kênh này

3) Máy chủ gửi bộ đệm nhận được bằng cách sử dụng đối tượng Comms Rcv với comms_phase_id được thiết lập là 0

4) CICAM xử lý bộ đệm 0

5) CICAM gửi Get_Next_Buffer với comms_phase_id được thiết lập là 0, để chỉ ra cho máy chủ rằng bộ đệm 0 có thể được lấp đầy

6) Máy chủ nhận dữ liệu trên kênh này

7) Máy chủ gửi một phn của dữ liệu nhận được bằng cách sử dụng đối tượng Comms Rcv với comms_phase_id được thiết lập là 1

8) Máy chủ gửi một phần của dữ liệu nhận được bằng cách sử dụng đối tượng Comms Rcv với comms_phase_id được thiết lập là 2

9) Máy chủ gửi một phần của dữ liệu nhận được bằng cách sử dụng đối tượng Comms Rcv với comms_phase_id được thiết lập là 3

10) Máy chủ gửi một phần của dữ liệu nhận được bằng cách sử dụng đối tượng Comms Rcv với comms_phase_id được thiết lập là 4

11) CICAM xử lý bộ đệm 1

12) CICAM gửi Get_Next_Buffer với comms_phase_id được thiết lập là 1, để chỉ ra cho máy chủ rằng bộ đệm 1 có thể được lấp đầy

13) CICAM xử lý bộ đệm 2

14) CICAM gửi Get_Next_Buffer với comms_phase_id được thiết lập là 2, để chỉ ra cho máy chủ rng bộ đệm 2 có thể được lp đầy

15) Máy chủ nhận dữ liệu trên kênh này

16) Máy chủ gửi bộ đệm đã nhận được bằng cách sử dụng đối tượng Comms Rcv với comms_phase_id được thiết lập là 5

17) CICAM xử lý bộ đệm 3

18) CICAM gửi Get_Next_Buffer với comms_phase_id được thiết lp là 3, để chỉ ra cho máy chủ rằng bộ đệm 3 có thể được lp đầy

19) CICAM xử lý bộ đệm 4 và 5

20) CICAM gửi Get_Next_Buffer với comms_phase_id được thiết lập là 5, để chỉ ra cho máy chủ rằng các bộ đệm 4 và 5 có thể được lấp đầy

14.1.4. Kiểm soát dòng của máy chủ

Với phiên bản 3 của tài nguyên truyền tốc độ thấp, máy chủ phải chấp nhận lên đến 16 bộ đệm trước khi CICAM kích hoạt kiểm soát dòng.

Khi CICAM phải gửi dữ liệu cho kênh này, CICAM sử dụng một comms_send APDU với comms_phase_id được thiết lập theo comms_send APDU comm_phase_id cuối cùng cộng với một (mô đun 16), hoặc không khi không có comms_send APDU đã được gửi từ khi mở phiên hoặc kết nối kênh.

 

Hình 14.2 - Kiểm soát dòng của máy chủ với 16 bộ đệm

Việc xác nhận việc truyền thông qua kênh này của một tập các bộ đệm liên tiếp được máy chủ chỉ ra bằng cách gửi comms_reply APDU với comms_reply_id = Send_Ack và return_value được thiết lập theo nhãn nhận dạng của bộ đệm cuối cùng trong tập các bộ đệm. Tập các bộ đệm được xác nhận để truyền được định nghĩa là comms_reply APDU cuối cùng với comms_reply_id = Send_Ack return_value cộng thêm một (mô đun 16), hoặc không khi không có comms_reply APDU với comms_reply_id = Send_Ack đã được gửi từ khi mở phiên hoặc kết nối kênh, đến comms_reply return_value hiện tại, bao gồm cả hai comms_reply.

CICAM phải dừng gửi comms_send APDU này khi tất cả các bộ đệm đã được gửi đến máy chủ để truyền cho kênh này không được xác nhận. CICAM phải đợi cho đến khi máy chủ xác nhận truyền một tập mới các bộ đệm trước khi gửi thêm comms_send APDU, nếu được yêu cầu.

Các bước trong hình 14.2 được mô tả dưới đây:

1) Sau khi một kết nối được thiết lập thành công trên kênh này, CICAM gửi 16 bộ đệm đến máy chủ với comms_phase_id từ 0 đến 15

2) Máy chủ truyền các bộ đệm 0 và 1 (với comms_phase_id = 0 và comms_phase_id = 1)

3) Máy chủ gửi đến CICAM một comms_reply với comms_reply_id = Send_Ack và return_value = 1 để xác nhận việc truyền tập các bộ đệm từ comms_phase_id = 0 đến comms_phase_id = 11

4) Máy chủ truyền các bộ đệm từ 2 đến 12

5) Máy chủ gửi đến CICAM một comms_reply với comms_reply_id = Send_Ack và return_value = 0 để xác nhận việc truyền tập các bộ đệm từ comms_phase_id = 2 đến comms_phase_id = 12

6) CICAM lấp đầy bộ đệm 0 và gửi nó cho máy chủ với comms_phase_id = 0

7) Máy chủ truyền các bộ đệm từ 13 đến 0

8) Máy chủ gửi đến CICAM một comms_reply với comms_reply_id = Send_Ack và return_value = 0 để xác nhận việc truyền tập các bộ đệm từ comms_phase_id = 13 đến comms_phase_id = 0

14.1.5. Yêu cầu đối với bộ đệm

• Các bộ đệm có kích thước lên đến 2048 byte phải được hỗ trợ trong cả hai hướng. CICAM có thể chọn một kích thước bộ đệm thấp hơn so với 2048 nếu được yêu cầu bằng cách gửi một lệnh Set_Params

• Máy chủ phải chấp nhận lên đến 16 bộ đệm được CICAM gửi trước khi việc kiểm soát dòng diễn ra

• Số lượng byte tối đa của bản tin trong comms_send () là 2048 byte

• Số lượng byte tối đa của bản tin trong comms_rcv () là 2048 byte

14.1.6. Hành vi ngắt kết nối

Khi một ngắt kết nối được thiết bị đầu cuối mạng khởi tạo, máy chủ phải truyền tất cả các bộ đệm đã nhận được đang chờ đến CICAM và sau đó phải gửi comms_reply () không mong muốn, xem đoạn cuối cùng của điều 8.7.1.5 trong EN 50221 [7]. Phn truyền tốc độ thấp vẫn mở và CICAM có thể yêu cầu một kết nối khác.

14.1.7. Truyền dữ liệu

Để truyền dữ liệu tải giữa CICAM và một thiết bị đầu cuối mạng thông qua máy chủ, trao đổi các APDU giữa máy chủ và CICAM được yêu cầu như sau:

CICAM chia tải của nó thành các khối có buffer_size byte. Các bộ đệm được lấp đầy hoàn toàn được gửi bằng một comms_send_more () APDU, bộ đệm cuối cùng (một phần hoặc toàn bộ) phải được gửi bằng comms_send_last (). CICAM không được gửi một bộ đệm được lấp đầy một phn bng một comms_snd_more () APDU. Máy chủ phải cung cấp dữ liệu tải này vào mạng sao cho thiết bị đầu cuối mạng có thể đọc chúng trong một bước.

Máy chủ gửi dữ liệu tải nhận được từ mạng đến CICAM sử dụng comms_rcv_more () hoặc comms_rcv_last () APDU. Máy chủ chia tải của nó thành các khối có buffer_size byte. Các bộ đệm được lấp đầy hoàn toàn được gửi bằng một comms_rcv_more () APDU ngay lập tức. Một bộ đệm được lp đầy một phần khi thời gian chờ hoặc gần thiết bị đầu cuối mạng phải được gửi bng một comms_rcv_last () APDU. Đối với một số giao thức, việc gần một thiết bị đầu cuối mạng có thể không được phát hiện một cách đáng tin cậy. CICAM không nên dựa vào comms_rcv_last () APDU để phát hiện sự kết thúc của tải này.

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

Lớp tài nguyên truyền tốc độ thấp theo quy định tại EN 50221 [7] được nâng cấp để cung cấp truyền hai chiều qua một kết nối IP. Điều này có thể được sử dụng để hỗ trợ các chức năng truy nhập có điều kiện và có thể được sử dụng kết hợp với các dịch vụ tương tác. Phiên bản 2 trở lên của tài nguyên truyền tốc độ thấp bao gồm kết nối IP.

Máy chủ phải có khả năng thiết lập một kết nối IP bên ngoài và quản lý nó.

Ngăn xếp IP của máy chủ phải tuân thủ các tiêu chuẩn sau đây:

RFC768 (UDP)

RFC793 (TCP)

RFC791 (IPv4)

Việc hỗ trợ IPv6 và IPv4 multicast là tùy chọn trên máy chủ.

Việc thực hiện IPv4 multicast phải tuân thủ RFC1112 (IGMPv1). Việc hỗ trợ IPv6 trên máy chủ phải tuân thủ RFC2460 (IPv6) và RFC4443 (ICMPv6).

Đối với tất cả các kết nối multicast, protocol_type trong nhãn mô tả IP phải là UDP.

Nếu nhãn mô tả IP trong comms_cmd APDU của CICAM chứa một giá trị không hợp lệ hoặc loại kết nối được yêu cầu là không có sẵn trên máy chủ, máy chủ phải từ chối việc tạo kết nối. Điều này được thực hiện bằng cách trả lời bằng một comms_reply APDU với comms_reply_id được thiết lập là Send_Ack và return_value được thiết lập là 0 (xem EN 50221, điều 8.7.1.5)

Máy chủ chỉ hỗ trợ một kết nối cho mỗi phiên, nhưng máy chủ có thể hỗ trợ nhiều phiên song song.

Các bản tin được truyền phải giống như được mô tả trong EN 50221 [7] điều 8.7.

Các nội dung của tải phải theo Network Byte Order.

Hình 14.3 Định dạng gói tin truyền tải

Trên kết nối TCP, máy chủ có thể gửi các tải của các comms_send_more () hoặc comms_send_last () APDU đến mạng ngay lập tức vì TCP cung cấp bộ đệm và truyền đáng tin cậy.

Trên kết nối UDP, máy chủ phải đệm tất cả các ti comms_send_more đến () cho đến khi nó nhận được một comms_send_last () hoặc kích thước của tất cả các tải của bộ đệm vượt quá kích thước của tất cả các bộ đệm gửi sẵn có. Sau đó nó phải gửi dữ liệu này đến mạng trong một bước.

Máy chủ có thể đọc dữ liệu TCP từ mạng trong các khối có độ dài bất kỳ phù hợp cho việc chuyển tiếp dữ liệu trong các comms_rcv_more () và comms_rcv_last () APDU.

Khi đọc dữ liệu UDP từ mạng, máy chủ phải đảm bảo rằng nó đọc một gói hoàn chỉnh và không có dữ liệu bị loại bỏ trong quá trình đọc. Mỗi gói hoàn chỉnh được đọc theo cách này nên được chia thành các comms_rcv_more () và comms_rcv_last () APDU.

14.2.1. Sửa đổi Commms Cmd

Một loại kết nối mới được bổ sung vào đối tượng connection descriptor để cung cấp các thông số dành cho một kết nối IP đối với tài nguyên truyền tốc độ thấp.

Bảng 14.4 - Mã hóa đối tượng connection descriptor

Bảng "connection_descriptor" này được sửa đổi để bao gồm các loại nhãn mô tả dành cho liên kết Ethernet.

Bảng 14.5 - Connection Descriptor Type

connection_descriptor_type

Giá trị của loại

Sl_Telephone_Descriptor

01

Cable_Return_Channel_Descriptor

02

IP_Descriptor

03

Hostname_descriptor

04

Tất cả các giá trị khác được dự phòng

 

14.2.1.1. Comms Cmd IP_descriptor

Cú pháp nhãn mô tả IP này được quy định trong Bảng 14.7

Bảng 14.6 - IP Descriptor

Cú pháp

S bit

Kiểu

IP_descriptor() {
descriptor_tag

descriptor_length
IP_protocol_version
IP_address
destination_port
protocol_type
}



8
8
8
128
16
8



uimsbf
uimsbf
uimsbf
uimsbf
uimsbf
uimsbf

descriptor_tag: descriptor_tag dành cho IP_descriptor là 0xCF.

descriptor_length: độ dài nhãn mô tả này là một trường 8-bit xác định tổng số byte của phần dữ liệu của IP_descriptor theo sau byte xác định giá trị của trường này.

IP_protocol_version: trường này xác định phiên bản của giao thức IP

Bảng 14.7 - Các phiên bản của giao thức

IP_Protocol_version

Giá trị của loại

Dự phòng

0x00

IPv4

0x01

IPv6

0x02

Tất cả các giá trị khác được dự phòng

0x03-0xFF

IP_address: trường này xác định địa chỉ IP đích. Trong IPv4,12 byte đầu tiên bằng "0".

destination_Port: trường này xác định cổng đích được máy chủ sử dụng, cổng thu nhận này được máy chủ quản lý.

protocol_type: trường này được sử dụng để xác định giao thức được sử dụng; UDP hoặc TCP.

Bảng 14.8 - Các loại giao thức

protocol_type

Giá trị của loại

Dự phòng

0x00

TCP

0x01

UDP

0x02

Tất cả các giá trị khác được dự phòng

0x03-0xFF

14.2.1.2. Comms Cmd Hostname_descriptor

Bảng 14.9 - Hostname_descriptor

Cú pháp

Số bit

Kiểu

Hostname_descriptor() {
descriptor_tag
descriptor_length
protocol_type
destination_port
for (i=0; i<n; i++) {
Hostname_byte
}
}


8
8
8
16

8


uimsbf
uimsbf
uimsbf
uimsbf

uimsbf

descriptor_tag: descriptor_tag dành cho Hostname_descriptor là 0xCD.

descriptor_length: độ dài nhãn mô tả là một trường 8-bit xác định tổng số byte của phần dữ liệu của hostname_descriptor theo sau byte xác định giá trị của trường này.

protocol_type: trường này được sử dụng để xác định giao thức được sử dụng; UDP hoặc TCP.

destination_Port: trường này xác định cổng đích được máy chủ sử dụng, cổng thu nhận này được máy chủ quản lý.

Hostname_byte: Các byte dữ liệu tạo thành tên của máy chủ, ví dụ FQDN. Tham kho RFC1123 [40], điều 2.1.

14.2.1.3 Số lượng tối đa các kết nối đồng thời

Một CICAM có thể yêu cầu một máy chủ để mở các phiên truyền tốc độ thấp bổ sung cho phiên truyền hiện tại qua hai hay nhiều kết nối IP. Tùy thuộc vào khả năng của máy chủ, máy chủ có thể chấp nhận hoặc từ chối các kết nối bổ sung này. Việc từ chối có thể biểu hiện bởi chính nó tới CICAM như là một lỗi về việc mở một phiên làm việc mới trên các tài nguyên LSC hoặc như comms_reply (Connect Ack) với một lỗi không rõ ràng (theo phụ lục E.14.1).

Các lỗi phiên mới thường xảy ra khi máy chủ không có đủ bộ nhớ để nhớ đệm một kết nối mới. Các lỗi comms_reply xảy ra khi máy chủ không có khả năng thiết lập một kết nối cho các giao thức lớp ứng dụng yêu cầu.

Các CICAM phải đủ mạnh để xử lý cả hai tình huống lỗi. Các CICAM nên quản lý số lượng tối đa máy chủ kết nối đồng thời bằng cách đóng các kết nối mà không được sử dụng hoặc yêu cầu một kích thước bộ đệm nhỏ hơn bằng cách gửi một comms_cmd (Set_Params).

14.2.1.4 Hành vi Set_Params

Các comms_cmd () APDU là có liên quan đến lệnh Set_Params như mô tả trong phần 14.1.1. Phần này nêu rõ các hành vi Set Params yêu cầu. Lệnh Set_Params được gửi đi sau khi một comms_cmd (connect_on_channel) trước khi chuyển giao được khởi xướng theo R206-001:1998 [24], như hình dưới đây:

CICAM

Lệnh

Máy chủ

Yêu cầu một phiên với tài nguyên truyền tốc độ thấp

(... open_session ...)

èç

Nếu đây là một tài nguyên miễn phí thì phiên được cho phép

Request for a connection on a channel.

Yêu cầu cho một kết nối trên một kênh

comms_cmd (Connect_on_Channel)

è

Cố gắng kết nối vào kênh

 

comms_reply (Connect_Ack)

ç

Kết nối được kết thúc với các trạng thái

Cấu hình các thông số nhận và kích thước bộ đệm.

comms_cmd (Set_Params)

è

 

 

comms_reply (Set_Params_Ack)

ç

Các thông số truyền được thiết lập

Sau khi một kết nối thành công được thiết lập, các vấn đề Get_Next_Buffer của CICAM với comms_phase_id thiết lập thành 15, để chỉ báo tới máy chủ rằng các thông số bộ đệm Buffers từ 0 đến 15 có thể được điền vào.

comms_cmd (Get_Next_Buffer, comms_phase_id = 15)

è

Máy chủ nhận dữ liệu trên kênh

 

comms_rcv (comms_phase_id = 0, data)

ç

Máy chủ gửi các bộ đệm nhận được sử dụng đối tượng Comms Rcv với giá trị comms_phase_id thiết lập về 0.

14.2.2. Sửa đổi các loại tài nguyên truyền tốc độ thấp

Các giá trị mới của các loại tài nguyên truyền tốc độ thấp được bổ sung để hỗ trợ kết nối IP.

9

8

7

6

5

4

3

2

1

0

device type (kiểu thiết bị)

device no. (số hiệu thiết bị)

Hình 14.4 - Cấu trúc các loại tài nguyên truyền

Trường về loại của thiết bị được quy định tại Bảng 14.10

Bảng 14.10 - Các loại thiết bị truyền

Mô tả

Giá tr

Các modem

0x00-0x3F

Các cng nối tiếp

0x40-0x4F

Kênh trả về của cáp

0x50

Dự phòng

0x51-0x5F

Kết nối IP

0x60

Dự phòng

0x61-0xFF

CHÚ THÍCH: Bảng này thay thế điều 8.8.1.1 trong tài liệu EN 50221 [7]

device no. phải là 0 đối với loại thiết bị kết nối IP.

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

14.3.1. Giới thiệu

Phần mềm CICAM ngày càng trở nên phức tạp, để đm bảo chức năng và an ninh của một CICAM trong lĩnh vực này, việc nâng cấp phần mềm có thể là cần thiết. Việc nâng cấp firmware có thể có sẵn trên mạng bng cách sử dụng thông tin được chứa trong một hoặc nhiều dòng truyền tải.

Các DVB CICAM hiện nay có thể thực hiện việc nâng cấp phần mềm nhưng bản quy định kỹ thuật hiện tại không cung cấp bất kỳ giao diện chuẩn hóa giữa máy chủ và CICAM để phối hợp việc tải về phần mềm. Tiêu chuẩn này giới thiệu một phương pháp chuẩn để xử lý việc nâng cấp phần mềm cho phép CICAM thương lượng với máy chủ và hệ thống CA để thực hiện việc nâng cấp.

Tiêu chuẩn này quy định một giao diện tài nguyên và đảm bảo rằng việc nâng cấp phần mềm không dành cho các phương pháp báo hiệu độc quyền. Phần này xác định về báo hiệu và đồng bộ giữa CICAM và máy chủ, việc truyền và báo hiệu thực tế của việc nâng cấp phần mềm CICAM không được tiêu chuẩn này quy định và có thể sử dụng các cơ chế nâng cấp phần mềm truyền hình tiêu chuẩn như DVB-SSU hoặc cơ chế truyền độc quyền do nhà điều hành hoặc cung cấp CA xác định.

Việc nâng cấp CAM có thể bắt đầu một hoạt động dò kênh của máy chủ dưới sự kiểm soát của CICAM như một phần của quá trình nâng cấp bằng cách sử dụng Host control tune() APDU hoặc Host control tune_broadcast_req() APDU. Tiêu chuẩn này quy định Host control tune() APDU và Host control tune_broadcast_req() APDU.

14.3.2. Các nguyên tắc

Quá trình nâng cấp CICAM xem xét các yêu cầu khác nhau từ:

• Nhà cung cấp CA

• Nhà điều hành dịch vụ

• Máy chủ (TV hoặc thiết bị ghi lại)

Một CICAM truy nhập có điều kiện điển hình cung cấp hai chế độ hoạt động nâng cấp phn mềm khác nhau được gọi là "trì hoãn" và "ngay lập tức" đáp ứng yêu cầu khác nhau của hệ thống CA:

Chế độ ngay lập tức được sử dụng khi việc nâng cấp phần mềm được yêu cầu ngay lập tức. CICAM dừng xử lý các dịch vụ được CA bảo vệ cho đến khi một bản nâng cấp đã hoàn thành thành công.

Chế độ trì hoãn được sử dụng khi việc nâng cấp phần mềm có thể được hoãn lại. CICAM tiếp tục xử lý các dịch vụ được CA bảo vệ và cho phép việc nâng cấp lên được dời lại xảy ra tại một thời điểm thích hợp hơn. Điều này có thể được máy chủ tự động xác định, giảm thiểu sự gián đoạn dịch vụ, hoặc được người sử dụng kiểm soát một cách rõ ràng. Việc nâng cấp phần mềm chế độ trì hoãn có thể được một số phiên bản khác hoặc một số tiêu chí của hệ thống CA khác xác định.

CICAM không được thực hiện bất kỳ yêu cầu nâng cấp phần mềm trừ khi một dịch vụ CA đã được một ca_pmt lựa chọn. CICAM này có thể trên một transponder truyền hoặc thông báo tính sẵn sàng nâng cấp phần mềm, trừ khi một dịch vụ CA hiện đang được chọn thì CICAM không được bắt đầu bất kỳ sự tương tác về nâng cấp. CICAM có thể âm thm tiến hành việc tải về bản nâng cấp với điều kiện là không có sự gián đoạn đối với dòng truyền tải và biết rằng transponder này có thể bị thay đổi bt cứ lúc nào.

14.3.3. Quá trình nâng cấp CAM

Quá trình nâng cấp phần mềm cơ bản này được thể hiện trong Hình 14.5 theo một trình tự các bước sau:

Hình 14.5 - Quá trình nâng cấp CAM

Quá trình này được quy định như sau:

1) Chờ đợi một tín hiệu kích hoạt thông báo tính sẵn có của việc nâng cấp phần mềm mới dành cho CICAM. Hệ thống CA và nhà điều hành dịch vụ xác định cách hệ thống thiết bị đầu cuối thông báo tính sẵn có của việc nâng cấp firmware đến CICAM đã được công nhận trong hệ thống truyền hình.

2) Chờ máy chủ thực hiện một lựa chọn dịch vụ đối với dịch vụ CA, được xác định bằng CA System Id trong ca_pmt hiện tại.

3) Tài nguyên CAM_upgrade được mở ra và CICAM thông báo cho máy chủ về tính sẵn có của việc nâng cấp phần mềm bao gồm cả chế độ nâng cấp. CICAM chờ đợi máy chủ trả lời để xác định cách nâng cấp được tiến hành.

4) Chế độ tải về và trả lời của máy chủ xác định cách CICAM phải xử lý việc tải về phần mềm có thể được bắt đầu.

14.3.3.1. Quá trình bị trì hoãn

Hình 14.6 - Quá trình bị trì hoãn

Khi việc nâng cấp bị trì hoãn được Thiết bị đầu cuối yêu cầu, quá trình trì hoãn được bắt đầu ngay sau khi CICAM nhận được trả lời từ máy chủ.

Tùy theo trả lời của máy chủ, CICAM có các trạng thái sau:

Nếu trả lời của máy chủ là "Không" thì CICAM đóng phiên CAM_upgrade và quá trình CAM_upgrade bị dừng lại.

Nếu trả lời của máy chủ là "Có" thì CICAM tùy chọn mở một phiên họp về DVB Host Control để gửi một bản tin yêu cầu dò kênh và thực hiện tải phần mềm về CICAM

Nếu trả lời của máy chủ là "Hỏi" thì CICAM hiển thị một cuộc đối thoại MMI để thông báo cho người sử dụng đầu cuối về tính sẵn có của việc nâng cấp CAM này. CICAM bắt đầu hoặc dừng quá trình ti về phần mềm tùy thuộc vào thông tin phản hồi của người sử dụng (chấp nhận hoặc từ chối).

14.3.3.2. Quá trình ngay lập tức

Hình 14.7 - Quá trình ngay lập tức

Khi việc nâng cấp ngay lập tức được thiết bị đầu cuối yêu cầu thì CICAM dừng việc giải xáo trộn CA cho đến khi việc nâng cấp đã nhận được và cài đặt thành công, quá trình này được thể hiện trong hình 14.7.

CICAM thông báo cho máy chủ việc nâng cấp bằng cách sử dụng tài nguyên CAM_upgrade và chờ đợi trả lời này để xử lý như sau:

Khi máy chủ trả lời là "Có" CICAM khởi tạo quá trình nâng cấp phần mềm ngay lập tức. Điều này có thể yêu cầu CICAM mở một phiên đến tài nguyên Host Control Tune để thực hiện hoạt động dò kênh để có được việc nâng cấp này.

Khi máy chủ trả lời là "Hỏi" CICAM hiển thị một cuộc đối thoại MMI để thông báo cho người sử dụng về tính sẵn có của việc nâng cấp và yêu cầu sự cho phép để thực hiện nâng cấp. CICAM hoặc phải tiếp tục nâng cấp hoặc dừng quá trình này phụ thuộc vào trả lời của người sử dụng (chấp nhận hoặc từ chối). Khi việc nâng cấp bị dừng lại, người sử dụng chỉ có thể dò kênh đến dịch vụ FTA vì không có dịch vụ CA nào được giải xáo trộn. Khi người sử dụng chấp nhận nâng cấp thì máy chủ phải cho phép việc nâng cấp phần mềm được hoàn thành, tùy chọn hiển thị thanh chỉ thị quá trình này. Việc can thiệp của người sử dụng phải bị vô hiệu cho đến khi việc nâng cấp đã hoàn thành.

14.3.4. Giao thức nâng cấp CAM

14.3.4.1. Chế độ trì hoãn

Đối với một nâng cấp bị trì hoãn, CICAM chờ đợi máy chủ lựa chọn một dịch vụ CA bằng một ca_pmt trong đó bao gồm một nhãn mô tả CA với một CA system ID nâng cấp phù hợp. Khi một dịch vụ như vậy được lựa chọn, CICAM mở tài nguyên nâng cấp CAM, nếu nó chưa được mở, và gửi một cam_firmware_upgrade APDU để bắt đầu một quá trình nâng cấp bị trì hoãn.

Máy chủ phải trả lời yêu cầu này bằng một cam_firmware_upgrade_reply bao gồm một trạng thái trong tham số ‘answer, chế độ hoạt động này của máy chủ có khả năng để xác định trả lời tức là kiểm soát của người sử dụng hoặc tự động/không giám sát. CICAM sẽ sử dụng trả lời của máy chủ để xác định cách để tiếp tục quá trình nâng cấp.

Nếu việc nâng cấp này đã được chấp nhận thì trước tiên CICAM phải gửi bản tin cam_firmware_upgrade_progress để chỉ ra rằng một quá trình nâng cấp phần mềm đã bắt đầu. Sau đó CICAM có thể sử dụng các DVB Host Control APDU để gửi một hoặc nhiều yêu cầu tune () hoặc tune_broadcast () để xác định vị trí và lựa chọn dịch vụ tải về, sau đó quá trình tải về phải được thông báo mỗi 20 giây bằng những bản tin cam_firmware_upgrade_progress. Khi quá trình nâng cấp đã hoàn thành thì CICAM gửi cam_firmware_upgrade_complete APDU.

Nếu việc nâng cấp không được chấp nhận nó có thể được cố thử lại lần tiếp theo, máy chủ lựa chọn một dịch vụ CA bằng một ca_pmt trong đó bao gồm một nhãn mô tả CA với một CA system ID nâng cấp phù hợp. CICAM không được cố thử lại một nâng cấp trước thời điểm này. CICAM có thể lựa chọn để trì hoãn một cố thử nâng cấp cho đến một thời gian sau khi máy chủ một lần nữa lựa chọn một dịch vụ CA bằng một ca_pmt trong đó bao gồm một nhãn mô tả CA với một CA system ID nâng cấp phù hợp.

cam_firmware_upgrade_complete APDU chỉ ra cho HOST xem có yêu cầu thiết lập lại CICAM để hoàn thành quá trình nâng cấp. Khi nhận được cam_firmware_upgrade_complete APDU, máy chủ phải thực hiện bất kỳ việc thiết lập lại được yêu cầu và có thể lấy lại việc kiểm soát bộ dò kênh.

Máy chủ phải tránh tương tác của người sử dụng ảnh hưởng đến việc tải xuống ngay sau khi đã nhận được cam_firmware_upgrade_ APDU đầu tiên và cho đến khi nhận được một cam_firmware_upgrade_complete. Nếu máy chủ không nhận được cam_firmware_upgrade_progress APDU trong khoảng thời gian 60 giây thì nó có thể giả định rằng CICAM đã thất bại và cố gắng khôi phục hồi máy chủ.

Trình tự nâng cấp bị trì hoãn được thể hiện trong hình 14.8.

Hình 14.8 - Giao thức nâng cấp bị trì hoãn

14.3.4.2. Chế độ ngay lập tức

Đối với việc nâng cấp ngay lập tức, CICAM phải ngăn chặn việc giải xáo trộn tất cả các dịch vụ CA System Id cho đến khi việc nâng cấp phần mềm mới đã được cài đặt. Khi người sử dụng chọn một dịch vụ được CA xáo trộn, CICAM mở tài nguyên nâng cấp CAM, nếu nó chưa được mở, và gửi một cam_firmware_upgrade APDU để bắt đầu một quá trình nâng cấp ngay lập tức.

Khi nhận được, máy chủ trả lời bằng một cam_firmware_upgrade_reply chỉ ra rằng máy chủ sẵn sàng bằng tham số 'answer'. Tùy thuộc vào trả lời từ máy chủ mà CICAM phải dừng việc thương lượng nâng cấp hoặc tiến hành để bắt đầu quá trình nâng cấp.

Nếu việc nâng cấp này đã được chấp nhận thì trước tiên CICAM phải gửi bản tin cam_firmware_upgrade_progress để chỉ ra rằng một quá trình nâng cấp phần mềm đã bắt đầu. Sau đó CICAM có thể sử dụng các DVB Host Control APDU để gửi một hoặc nhiều yêu cầu tune() để xác định vị trí và lựa chọn dịch vụ tải về, sau đó quá trình tải về phải được thông báo mỗi 20 giây bằng những bản tin cam_firmware_upgrade_progress. Khi quá trình nâng cấp đã hoàn thành thì CICAM gửi cam_firmware_upgrade_complete APDU.

Nếu việc nâng cấp này không được chấp nhận thì nó có thể cố thử lại lần tiếp theo, máy chủ lựa chọn một dịch vụ CA bằng một ca_pmt trong đó bao gồm một nhãn mô tả CA với một CA system ID nâng cấp phù hợp. CICAM không được cố thử lại một nâng cấp trước thời điểm này. CICAM có thể lựa chọn để trì hoãn một nỗ lực nâng cấp cho đến một thời gian sau khi máy chủ một lần nữa lựa chọn một dịch vụ CA bằng một ca_pmt trong đó bao gồm một nhãn mô tả CA với một CA system ID nâng cấp phù hợp.

cam_firmware_upgrade_complete APDU chỉ ra cho HOST xem có yêu cầu thiết lập lại CICAM để hoàn thành quá trình nâng cấp. Khi nhận được cam_firmware_upgrade_complete APDU, máy chủ phải thực hiện bất kỳ việc thiết lập lại được yêu cầu và có thể lấy lại việc kiểm soát bộ dò kênh.

Hình 14.9 - Giao thức nâng cấp ngay lập tức

Máy chủ phải tránh tương tác của người sử dụng nh hưng đến việc tải xung ngay sau khi đã nhận được cam_firmware_upgrade_APDU đầu tiên và cho đến khi nhận được một cam_firmware_upgrade_complete. Nếu máy chủ không nhận được cam_firmware_upgrade_progress APDU trong khoảng thời gian 60 giây thì nó có thể giả định rằng CICAM đã thất bại và cố gắng khôi phục hồi máy chủ.

14.3.4.3. Gián đoạn nâng cấp

Quá trình nâng cấp CICAM có thể bị gián đoạn vì một số lý do:

• CICAM bị thiết lập lại

• Tắt nguồn điện

CICAM bị thiết lập lại

Một quá trình nâng cấp CICAM, không phân biệt chế độ, phải được khởi tạo lại hoàn toàn khi dịch vụ CA System ID được lựa chọn.

Tắt nguồn điện/khôi phục

Máy chủ và CICAM có thể bị ảnh hưởng của sự cố tắt nguồn điện bất cứ lúc nào trong hoạt động nâng cấp, CICAM phải có khả năng phục hồi và bắt đầu việc nâng cấp khi lựa chọn một dịch vụ CA System ID. CICAM không được khôi phục việc nâng cấp có gây ra bất kỳ sự gián đoạn của dòng truyền tải hoặc người sử dụng (thông qua các bản tin MMI) khi không lựa chọn một dịch vụ CA System ID.

14.3.4.4. Thực hiện thiết lập lại

Khi CICAM đã hoàn thành việc nâng cấp firmware, nó phải gửi cam_firmware_upgrade_complete APDU với loại thiết lập lại thích hợp.

14.3.4.5. Hoạt động của máy chủ

1) Máy chủ phải hỗ trợ tài nguyên CAM_upgrade và quản lý DVB Host Control Resource

2) Chế độ hoạt động của máy chủ phải xác định trạng thái trở lại của CICAM thông qua cam_firmware_upgrade_reply.

3) Trả lời của máy chủ đối với bản tin cam_firmware_upgrade_reply phải tuân theo Bảng 14.12:

Bảng 14.11 - Các trạng thái trả lời nâng cấp của máy chủ

 

Xử lý sau

Xử lý ngay lập tức

Chế độ người dùng

Hỏi

Hỏi

Chế độ tự động

Không

Chế độ dịch vụ

4) Trong chế độ hoạt động bình thường (chế độ người sử dụng), trả lời phải là ASK (0x02). Điều này có nghĩa rằng người sử dụng đang xem một dịch vụ CA và CICAM cung cấp một dấu hiệu về tính sẵn có của việc nâng cấp cho người sử dụng.

5) Trong chế độ tự động (tức là ghi lại), trong chế độ nâng cấp trì hoãn, trả lời có khả năng là NO (0x00) cho phép việc ghi lại tiếp tục mà không bị gián đoạn, bất kỳ việc nâng cấp sẽ bị trì hoãn đến một thời gian sau này thuận tiện nhiều hơn. Đối với chế độ nâng cấp ngay lập tức thì trả lời phải là CÓ (0x01), trong đó việc nâng cấp phải được bắt đầu ngay khi có thể và có thể dẫn đến một phần của bất kỳ chương trình bị bỏ qua.

6) Trong chế độ dịch vụ (tức là nâng cấp phần mềm máy chủ, phát triển mạng v.v..) trả lời có thể là có (0x01) dành cho tất cả các loại quá trình nâng cấp và CICAM có thể bắt đầu quá trình nâng cấp ngay lập tức.

7) CICAM phải quản lý các thông báo quá trình này cho người sử dụng bằng có sử dụng MMI.

8) Máy chủ quản lý việc thiết lập lại CICAM khi hoàn thành việc nâng cấp và máy chủ phải trở lại hoạt động bình thường với CICAM trong tất cả các khía cạnh, bao gồm cả hoạt động thời gian chờ và thiết lập lại.

14.3.4.6. Hy bỏ nâng cấp

Nếu CICAM hủy bỏ nâng cấp phần mềm thì nó phải gửi cam_firmware_upgrade_complete APDU với loại thiết lập lại được thiết lập là 0x02 "không yêu cầu thiết lập lại".

14.3.5. Tài nguyên CAM_Upgrade

Tài nguyên CAM_Upgrade cho phép CICAM phối hợp quá trình nâng cấp phần mềm CICAM với máy chủ. Các bản tin này cho phép CICAM bắt đầu tải xuống với một số thỏa thuận từ thiết bị máy chủ, thông báo quá trình nâng cấp này và cuối cùng thông báo hoàn thành. Máy chủ được cung cấp những thông tin về sự cấp thiết của việc nâng cấp để cho máy chủ xác định khi nào yêu cầu sự can thiệp của người sử dụng phụ thuộc vào chế độ hoạt động hiện tại của nó.

14.3.5.1. Các APDU của tài nguyên CAM_Upgrade

CICAM mở tài nguyên CAM_Upgrade khi việc nâng cấp firmware được yêu cầu. Tài nguyên CAM_Upgrade hỗ trợ các đối tượng sau:

Bảng 14.12 - Các CAM_Upgrade APDU

CAM Upgrade APDU

Chiều

cam_firmware_upgrade

CICAM □ HOST

cam_firmware_upgrade_reply

CICAM □ HOST

cam_firmware_upgrade_progress

CICAM □ HOST

cam_firmware_upgrade_complete

CICAM HOST

14.3.5.2. cam_firmware_upgrade APDU

CICAM phải truyền cam_firmware_upgrade APDU này đến máy chủ để thông báo cho nó về chế độ nâng cấp được hệ thống CA hoặc nhà điều hành hệ thống yêu cầu. Đối tượng này bao gồm thông tin về sự cấp thiết của việc tải về và thời gian hoàn thành dự kiến.

Bảng 14.13 - Cú pháp đối tượng nâng cấp Firmware

Cú pháp

Số bit

Kiểu

cam_firmware_upgrade() {
cam firmware upgrade tag
length_field()
upgrade_type
download time
}


24

8
16


uimsbf

uimsbf
uimsbf

cam_firmware_upgrade_tag: xem Bảng L.1 tại Phụ lục L.

upgrade_type: tham số này xác định loại nâng cấp phần mềm CAM được yêu cầu:

0x00: Chế độ nâng cấp trì hoãn

0x01: Chế độ nâng cấp ngay lập tức

download_time: Thời gian theo giây, dự kiến để hoàn thành quá trình nâng cấp firmware. Nếu giá trị là 0x0000 thì thời gian này là không xác định.

14.3.5.3. cam_firmware_upgrade_reply APDU

Máy chủ trả lời cam_firmware_upgrade APDU. CICAM không được bắt đầu hoạt động tải về này cho đến khi nó nhận được trả lời này.

Bảng 14.14 - Cú pháp APDU trả lời nâng cấp Firmware

Cú pháp

Số bit

Kiểu

cam_firmware_upgrade_reply() {
cam_firmware_upgrade_reply_tag
length_field()
answer
}


24

8


uimsbf

uimsbf

cam_firmware_upgrade_reply_tag: xem Bảng L.1 tại Phụ lục L.

answer: Trả lời của máy chủ có các giá trị có thể sau đây:

• 0x00 có nghĩa là KHÔNG/NO.

• 0x01 có nghĩa là CÓ/YES.

• 0x02 có nghĩa là HỎI/ASK người sử dụng. CICAM phi mở hội thoại MMI để nhận được trả lời của người sử dụng.

• 0x03-0xFF dự phòng trong tương lai.

14.3.5.4. cam_firmware_upgrade_progress APDU

Sau khi CICAM đã bắt đầu việc nâng cấp của nó, nó truyền cam_firmware_upgrade_progress () APDU đến máy chủ để thông báo cho nó về quá trình tải về phần mềm. Bản tin này được gửi theo định kỳ 20 giây, từ CICAM đến máy chủ. Máy chủ sử dụng đối tượng này để đảm bảo rằng CICAM vẫn còn hoạt động trong quá trình nâng cấp phần mềm. Nếu không nhận được đối tượng này (và cập nhật) trong một thời gian quá 60 giây trong suốt thời gian tải về thì máy chủ có thể cố thử khôi phục CICAM bằng cách thiết lập lại v.v..

Bảng 14.15 - Cú pháp APDU quá trình nâng cấp Firmware

Cú pháp

Số bit

Kiểu

cam_firmware_upgrade__progress() {
cam_firmware_upgrade_progress_tag
length_field()
download_progress_status
}


24

8


uimsbf

uimsbf

cam_firmware_upgrade_progress_tag: xem Bảng L.1 tại Phụ lục L.

download_progres_status: giá trị phn trăm của quá trình nâng cấp CAM, trong khoảng từ 0 đến 100 (tức là một tỷ lệ phần trăm hoàn thành).

14.3.5.5. cam_firmware_upgrade_complete APDU

Khi CICAM đã hoàn thành việc nâng cấp của nó, nó truyền cam_firmware_upgrade_complete () APDU đến máy chủ. Đối tượng này thông báo cho máy chủ rằng việc nâng cấp đã hoàn thành và xem CICAM có yêu cầu thiết lập lại. Bất kỳ các tài nguyên kiểm soát máy chủ được sử dụng trong quá trình nâng cấp phải được CICAM đóng trước khi gửi đối tượng này.

Bảng 14.16 - Cú pháp APDU hoàn thành nâng cấp Firmware

Cú pháp

S bit

Kiểu

cam_firmware_upgrade_complete() {
cam_firmware_upgrade_complete_tag
length_field()
reset_request_status
}


24

8


uimsbf

uimsbf

cam_firmware_upgrade_complete_tag: xem Bảng L.1 tại Phụ lục L.

reset_request_status: trường này chứa trạng thái thiết lập lại dành cho CICAM.

Bảng 14.17 - Các loại reset_request_status

Giá trị

Diễn giải

0x00

thiết lập lại PCMCIA được yêu cầu - Máy chủ thiết lập tín hiệu thiết lập lại là hoạt động sau đó là không hoạt động.

0x01

thiết lập lại CI Plus CAM được yêu cầu - Máy chủ thiết lập cờ RS và bắt đầu khởi tạo giao diện

0x02

thiết lập lại không được yêu cầu - Hoạt động bình thường vẫn tiếp tục

0x03 - 0xFF

Dự phòng

CHÚ THÍCH: Nếu CICAM muốn hủy nâng cấp firmware, nó có thể gửi APDU cam_firmware_upgrade_complete APDU với yêu cầu không thiết lặp lại. Máy chủ nhận được APDU này vẫn phải tiếp tục hoạt động bình thường.

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

Tài nguyên MMI ứng dụng, TS 101 699 [8], được mở rộng để cho phép trao đổi tập tin và dữ liệu theo cả hai hướng, điều này cho phép thông tin trạng thái được trả về từ miền ứng dụng đến mô-đun này. Những phần mở rộng chỉ được miền ứng dụng CI Plus sử dụng để truyền tập tin hoặc thông tin ống dữ liệu riêng. Phiên bản tài nguyên MMI ứng dụng này vẫn là 1 và các phần mở rộng CI Plus xác định các quy tắc đặt tên tập tin phải được sử dụng trong miền ứng dụng CI Plus "CIEngineProfile1".

14.4.1. Quy tắc đặt tên tập tin

Máy chủ phải luôn luôn bao gồm "CI://" ở phần đầu của bất kỳ một tên của tập tin nào được sử dụng trong hoạt động với tập tin tài nguyên MMI ứng dụng để đảm bảo khả năng phối hợp với các CICAM hiện có. Bất kỳ đường dẫn đưa vào một tên của tập tin phải được phân tích hoàn toàn, nó không được chứa thành phần đường dẫn tương đối ví dụ như "..". Để đảm bảo khả năng phối hợp với các máy chủ hiện có, CICAM phải phân tích được bất kỳ tham chiếu của tập tin MHEG sau:

• /mydir/myfile

• //mydir/myfile

• /myfile

• //myfile

• CI:/mydir/myfile

• CI://mydir/myfile

• CI:/myfile

• CI://myfile

14.4.2. FileRequest

Bản tin FileRequest được mở rộng (xem Bảng 14.18) để cho phép việc truyền tải này đến mô đun yêu cầu tập tin này theo quy định tại TS 101 699 [8] hoặc để thiết lập một ống dữ liệu riêng giữa máy chủ và mô-đun này.

Các ứng dụng có thể thực hiện không đồng bộ các yêu cầu tập tin của loại tập tin và nhiều FileRequests có thể được máy chủ gửi mà không cần chờ đợi một FileAcknowledge (tức là các yêu cầu tập tin không phải là tuần tự). CICAM phải xếp hàng các yêu cầu và trả về một FileAcknowledge cho mỗi FileRequest. CICAM tối thiểu phải có khả năng quản lý 8 FileRequests tại một thời điểm.

Đối với các bản tin của loại tập tin, FileResponse phải trả về dữ liệu ngay khi nó trở nên có sẵn, điều này có thể dẫn đến các bản tin FileResponse được nhận được theo một trật tự khác với các yêu cầu ban đầu. Bản tin của loại dữ liệu phải giữ theo trật tự và phải được CICAM xử lý theo trình tự và trả về một FileAcknowlegde theo thứ tự giống như FileRequest.

Bảng 14.18 - Bản tin FileRequest

Cú pháp

Số bit

Kiểu

FileReq() {
FileReqTag length_field()
RequestType
if (RequestType == 0) {
for (i=0; i<(n-1); i++) {
FileNameByte
}
}
if (RequestType == 1) {
for (i=0; i<(n-1); i++){
DataByte
}
}
}


24

8

8





8


uimsbf

bslbf

bslbf





bslbf

RequestType: Trường 8 bit này xác định loại yêu cầu mà máy chủ yêu cầu. Các giá trị RequestType được quy định tại Bảng 14.19.

Bảng 14.19 - Các giá trị RequestType trong FileRequest

RequestType

Giá trị

Tập tin (File)

0x00

Dữ liệu (Data)

0x01

Dự phòng

0x02-0xff

FileNameByte: Một byte của tên tập tin được yêu cầu hoặc một byte của ống dữ liệu để trả về mô đun. Diễn giải của byte được xác định trong phần RequestType.

DataByte: Một byte của dữ liệu được gửi đến mô đun này.

14.4.3. File Acknowledge

FileAcknowledge được mở rộng (xem Bảng 14.20) đ cho phép mô-đun này để trả về các byte của tập tin được yêu cầu hoặc ống dữ liệu đến máy chủ dành cho các bản tin MMI ứng dụng CI Plus.

Bảng 14.20 - Bản tin FileAcknowledge

Cú pháp

S bit

Kiểu

FileAck() {
FileAckTag
length_field()
Reserved
FileOK
RequestType
if (RequestType == File) {
FileNameLength
for (i=0; i<FileNameLength; i++) {
FileNameByte
}
FileDataLength
for (i=0; i<FileDataLength; i++) {
FileDataByte
}
}
if (RequestType == Data) {
for (i=0; i<(n-1); i++) {
DataByte
}
}
}


24

7
1
8

8

8

32

8





8


uimsbf

bslbf
bslbf
bslbf

uimsbf

bslbf

uimsbf

bslbf





bslbf

FileOK: Trường 1 bit này được thiết lập là "1" nếu tập tin này có sẵn hay là một trả lời để xác nhận bản tin FileRequestRequestType là dữ liệu, nếu khác nó phải là "0".

RequestType: Trường 8 bit này xác định kiểu yêu cầu mà máy chủ yêu cầu. Các giá trị RequestType được quy định tại Bảng 14.21

Bảng 14.21 - Các giá trị của RequestType trong FileAcknowledge

RequestType

Giá trị

Tập tin (File)

0x00

Dữ liệu( Data)

0x01

Dự phòng

0x02-0xff

FileNameLength: số byte trong tên tập tin.

FileNameByte: Tên của tập tin mà máy chủ yêu cầu. Điều này cho phép máy chủ yêu cầu việc truyền nhiều tập tin không đồng bộ trước khi xác nhận nhận được vì xác nhận này xác định tập tin của yêu cầu ban đầu. Tên tập tin được trả về phải giống như tên được cung cấp trong FileRequest ban đầu.

FileDataLength: Độ dài của nội dung của tập tin theo byte.

FileDataByte: Một byte của dữ liệu tập tin được ly ra. Lưu ý rằng các APDU không bị giới hạn ở 65535 byte. Xem Phụ lục E.9.

DataByte: Một byte của dữ liệu đã được gửi đến máy chủ.

14.4.4. AppAbortRequest

Máy chủ hoặc mô-đun này có thể ngăn chặn trước miền ứng dụng CI Plus, nó có thể được loại bỏ ngay lập tức mà không cần chờ đợi một AppAbortAcknowledge. Máy chủ phải gửi một AppAbortRequest APDU đến CICAM khi ứng dụng này bị đóng, điều này bao gồm, nhưng không giới hạn, khi công cụ ứng dụng này bị máy chủ từ chối cho phép bắt đầu, ứng dụng không được bắt đầu, ứng dụng thoát ra thông qua một lỗi hoặc khi ứng dụng tự nhiên thoát ra. AppAbortRequest hủy bỏ các mã dành cho miền ứng dụng CI Plus được quy định tại Bảng 14.22.

CICAM nên kết thúc bất kỳ ứng dụng đang chạy hiện tại một cách rõ ràng bằng một AppAbortRequest trước khi bắt đầu một ứng dụng mới với Requeststart vì thứ tự của một AppAbortRequest (ứng dụng hiện tại bị đóng) và RequestStartAck (ứng dụng mới bắt đầu) có thể không được máy chủ bảo đảm.

Bảng 14.22 - Các mã hủy bỏ ứng dụng

AbortReqCode

Ý nghĩa

0x00

Dự phòng.

0x01

Hủy bỏ bởi người sử dụng -Người sử dụng khởi đầu sự kết thúc của miền ứng dụng.

0x02

Hủy bỏ bởi hệ thống - Hệ thống xóa miền ứng dụng để thực hiện nhiệm vụ khác.

0x03-0xff

Dự phòng.

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

Tài nguyên MMI ứng dụng, TS 101 699 [8], được mở rộng cho phép lưu trữ nội dung trong thiết bị máy chủ để tăng tốc độ thực hiện ứng dụng CI. Những phần mở rộng này chỉ được miền ứng dụng CI Plus sử dụng để truyền tập tin hoặc thông tin ống dữ liệu riêng với phiên bản 2 của tài nguyên MMI ứng dụng.

Cơ chế lưu trữ được một RequestType mới gọi là FileHash cung cấp, cho phép máy chủ để tính toán một mã băm MD5 của nội dung tập tin và cho phép máy chủ yêu cầu một tập tin từ CICAM với cả tên tập tin và một mã băm nội dung được máy chủ tính. Khi nhận được yêu cầu FileHash, CICAM sử dụng mã băm của tập tin để xác định xem nội dung tập tin đã thay đổi, nếu mã băm của tập tin được CICAM tính giống mã băm trong yêu cầu bản tin thì nội dung tập tin không được trả về cho máy chủ và một chỉ thị được cung cấp trong bản tin trả lời cho biết rằng nội dung tập tin vẫn không thay đổi. Nếu mã băm tập tin là khác thì CICAM trả về các nội dung tập tin mới.

Cơ chế mã băm tập tin này cho phép băng thông giữa máy chủ và CICAM được giảm khi nội dung hiện có đã thu được từ đó tăng tốc độ thực hiện ứng dụng.

Tài nguyên MMI ứng dụng v2 cũng bao gồm một cơ chế dành cho RequestType được mở rộng trong tương lai mà không cần thiết phải tăng phiên bản của tài nguyên.

Yêu cầu CICAM hỗ trợ phiên bản v1 và v2 của tài nguyên MMI ứng dụng. Yêu cầu máy chủ hỗ trợ tài nguyên MMI ứng dụng v1 và có thể tùy chọn hỗ trợ v2 ngoài v1. Trừ khi có quy định khác, hành vi của tài nguyên MMI ứng dụng v1 giống với tài nguyên MMI ứng dụng v2 dành cho RequestType tập tin và dữ liệu.

14.5.1. FileRequest v2

Bản tin FileRequest được mở rộng (xem Bảng 14.23) để bao gồm hỗ trợ việc truyền tập tin được băm Cú pháp giống hệt với phiên bản 1 dành cho RequestType tập tin và dữ liệu.

Các ứng dụng có thể thực hiện không đồng bộ các yêu cầu tập tin của loại tập tin và FileHash. Nhiều FileRequest có thể được máy chủ cung cấp mà không cần chờ đợi một FileAcknowledge (tức là yêu cầu tập tin không phải là tuần tự). CICAM phải xếp hàng theo yêu cầu và tr về một FileAcknowledge cho mỗi FileRequest. CICAM phải có khả năng tối thiểu quản lý 8 FileRequest tại một thời điểm.

Đối với các bản tin của loại tập tin và FileHash, FileResponse phải trả về dữ liệu ngay khi nó có sẵn, điều này có thể dẫn đến việc các bn tin FileResponse nhận được trong một thứ tự khác so với yêu cầu ban đầu. Các bản tin của loại dữ liệu phải giữ theo trật tự và phải được CICAM xử lý theo trình tự và trả về một FileAcknowlegde theo thứ tự giống như FileRequest.

Bảng 14.23 - Bản tin FileRequest

Cú pháp

Số bit

Kiểu

FileReq() {
FileReqTag
length_field()
RequestType
if (RequestType == File) {
for (i=0; i<(n-1); i++) {
FileNameByte
}
}
if (RequestType == Data) {
for (i=0; i<(n-1): i++) {
DataByte
}
}
if (RequestType == FileHash) {
FileHash
for (i=0; i<(n-17); i++) {
FileNameByte
}
}
}


24

8


8




8



128

8


uimsbf

bslbf


bslbf




bslbf



bslbf

bslbf

RequestType: trường 8-bit này xác định loại của yêu cầu mà máy chủ yêu cầu. Các giá tr RequestType được quy định tại Bảng 14.24. Máy chủ không được gửi bất kỳ loại yêu cầu nào khác với tập tin (0x00), dữ liệu (0x01) hoặc FileHash (0x02) trừ khi khả năng tương thích với CICAM đã được xác nhận, tham khảo điều 14.4.4, Khôi phục loại yêu cầu v2.

Bảng 14.24 - Các giá trị RequestType

RequestType

Mô tả

Giá trị

File

Một file đang được yêu cầu mà không có bất kỳ điều khiển phiên bản

0x00

Data

Một mục dữ liệu đang được yêu cầu

0x01

FileHash

Một file đang được yêu cầu với trường phiên bản bị hỏng.

0x02

ReqTypes

Một danh sách các RequestType được hỗ trợ đang được yêu cầu

0x03

Dự phòng

Dự phòng

0x04-0x7f

Định nghĩa bởi người sử dụng

Định nghĩa bởi người sử dụng

0x80-0xff

FileNameByte: Một byte của tên tập tin được yêu cầu hoặc một ống byte dữ liệu để gửi đến mô-đun này. Diễn giải của byte được xác định trong phần RequestType.

DataByte: Một byte của dữ liệu được gửi đến mô-đun này.

FileHash: trường 128-bit này được thiết lập theo mã băm MD5 của các nội dung của tập tin này trên máy chủ với tên tập tin được gửi trong bản tin này. Thuật toán MD5 được định nghĩa trong RFC 1321.

14.5.2. FileAcknowledge v2

FileAcknowledge được mở rộng (xem Bảng 14.25) để cho phép mô-đun này trả về các byte của tập tin yêu cầu hoặc ống dữ liệu đến máy chủ dành cho các bản tin MMI ứng dụng CI Plus. Một trạng thái mở rộng của yêu cầu ban đầu được bao gồm trong bản tin trả lời phiên bản 2.

Bảng 14.25 - Bản tin FileAcknowledge

Cú pháp

Số bit

Kiểu

FileAck() {
FileAckTag
length_field()
Reserved_zero
RequestOK
FileOK
RequestType
if (RequestType == File) II (RequestType == FileHash) {
FileNameLength
for (i=0; i<FileNameLength; i++) {
FileNameByte
}
FileDataLength
for (i=0; i<FileDataLength; i++) { FileDataByte
}
}
if (RequestType == Data) {for (i=0; i<(n-1); i++) {
DataByte
}
}
if (RequestType == ReqTypes) {for (i=0; i<(n-1); i++) {
ReqTypeByte
}
}
}


24

6
1
1
8


8
8

32

8


8




8


uimsbf

bslbf
bslbf
bslbf
uimsbf


uimsbf
bslbf

uimsbf

bslbf


bslbf




uimsbf

Reserved_zero: trường 6-bit này được dự phòng trong tương lai và phải được thiết lập là không.

RequestOK: trường 1-bit này chỉ được phân tích trong phạm vi của một RequestType theo Bảng 14.26. Trường này được thiết lập là "0" khi giá trị trường này là không sử dụng.

Bảng 14.26 - Giá trí trạng thái RequestOK

RequestType

Request

RequestOK=0

RequestOK=1

0x00

File

Không sử dụng, giá trị trường bị bỏ qua.

0x01

Data

Không sử dụng, giá trị trường bị bỏ qua.

0x02

FileFlash

Yêu cầu không thành công vì không tìm thấy file hoặc yêu cầu không hợp lệ.

Yêu cầu thành công, trường FileOK cho biết liệu file đó đã thay đổi hay chưa.

0x03

ReqTypes

Không sử dụng, giá trị trường bị bỏ qua.

0x04-0xff

Dự phòng

Không sử dụng, giá trị trường bị bỏ qua.

FileOK: trường 1-bit này chỉ được phân tích trong phạm vi của một RequestType theo Bng 14.27. Trường này được thiết lập là "0" khi RequestType không xác định.

Bảng 14.27 - Giá tr trạng thái FileOK

RequestType

Request

FileOK=0

FileOK=1

0x00

File

File không tìm thấy hoặc không có sẵn.

File được yêu cầu có sẵn để dùng và các nội dung được gộp vào trong bản tin xác nhận.

0x01

Data

Dữ liệu không tìm thy hoặc không có sẵn.

Đây là một trả lời xác nhận thành công và nội dung dữ liệu có thể được gộp vào trong bản tin xác nhận.

0x02

FileHash

Khi RequestOK=1 các nội dụng file chưa thay đổi và phù hợp với file hash.

Khi RequestOK=0 yêu cầu không thành công.

Các nội dung file đã thay đổi và không phù hợp với file hash được yêu cầu. Các nội dung file mới được gộp vào trong bản tin xác nhận này.

0x03

ReqTypes

Lỗi xảy ra trong khi yêu cầu.

Đây là một trả lời xác nhận thành công và bản tin chứa một danh sách các RequestType được hỗ trợ của CICAM.

0x04-0xff

Dự phòng

Lệnh không biết hoặc không thành công.

Không được dành cho mục đích khác.

RequestType: trường 8-bit này xác định loại yêu cầu mà máy chủ yêu cầu. Các giá trị RequestType được quy định tại Bng 14.24.

FileNameLength: số byte trong tên tập tin.

FileNameByte: Tên của tập tin mà máy chủ yêu cầu. Việc trả về tên tập tin được yêu cầu cho phép máy chủ để yêu cầu không đồng nghĩa việc truyền nhiều tập tin trước khi nhận được xác nhận vì xác nhận này xác định tập tin được yêu cầu ban đầu. Tên tập tin được trả về phải giống như tên được cung cấp trong FileRequest ban đầu.

FileDataLength: Độ dài của các nội dung của tập tin này theo byte. Trường này phải được thiết lập là không trên RequestType của FileHash khi tập tin hiện có trên CICAM và FileHash của máy chủ giống mã băm của tập tin của CICAM tức là khi thông tin trạng thái được trả về là RequestOK = 1 và FileOK = 0.

FileDataByte: Một byte dữ liệu của tập tin đã được lấy ra. Lưu ý rằng các APDU không bị giới hạn ở 65535 byte. Xem Phụ lục E.12.

DataByte: Một byte của dữ liệu đã được gửi đến máy chủ.

ReqTypeByte: trường 8-bit này chứa RequestType được CICAM hỗ trợ. Mỗi RequestType được CICAM hỗ trợ phải được bao gồm trong trả lời và phải được trình bày theo thứ tự số tăng dần.

14.5.3. Khôi phục RequestType v2

Phiên bản 2 của tài nguyên MMI ứng dụng cho phép máy chủ truy vấn các RequestType được CICAM hỗ trợ để cho phép các RequestType bổ sung được thêm vào tài nguyên MMI ứng dụng mà không cần phải tăng phiên bản của tài nguyên. Máy chủ chỉ được sử dụng các RequestType tập tin, dữ liệu, FileHash và ReqTypes. Các RequestType khác với tập tin, dữ liệu, FileHash và ReqTypes chỉ có thể được máy chủ sử dụng sau khi truy vấn CICAM để xác nhận sự hiện có của RequestType được yêu cầu. RequestType này có thể không được máy chủ sử dụng nếu nó không được CICAM thông báo. CICAM phải chắc chắn về sự hiện có của một RequestType không xác định và phải luôn luôn trả lại trạng thái của FileOK là "0".

Để truy vấn các RequestType được CICAM hỗ trợ thì máy chủ gửi một bản tin FileRequest () với một RequestType ReqTypes là (0x03). CICAM phải trả lời bằng một bản tin FileAcknowledge () với một RequestType ReqTypes là (0x03), trường FileOK được thiết lập là "1" và trường ReqTypeByte này bao gồm mỗi RequestType được CICAM hỗ trợ và được sắp xếp theo thứ tự tăng dần, tức là nếu CICAM hỗ trợ tập tin, dữ liệu, FileHash và ReqTypes thì trường ReqTypeByte phải có độ dài 4 byte và chứa các byte 0x00, 0x01,0x02 và 0x03.

Ví dụ:

4 bytes (hex)

00010203

CICAM chỉ hỗ trợ 4 loại tài nguyên cơ bản v2 là tập tin (0x00), dữ liệu (0x01), FileHash (0x02) và ReqTypes (0x03).

5 byte (hex)

0001020304

CICAM hỗ trợ 5 giao thức. Các loại tài nguyên cơ bản v2 là tập tin (0x00), dữ liệu (0x01), FileHash (0x02) và ReqTypes (0x03), thêm vào một loại chưa được xác định là 0x04.

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

14.6.1. Kiểm soát máy chủ DVB phiên bản 2

Lớp tài nguyên kiểm soát máy chủ DVB theo quy định tại EN 50221 [7] được tăng cường để nó không còn bị giới hạn đối với việc dò kênh DVB triplet được máy chủ biết (kiểm soát máy phiên bản 1). Xem Phụ lục E.16 dành cho việc làm rõ hành vi dò kênh của kiểm soát máy chủ phiên bản 1. Phiên bản 2 của tài nguyên này thêm các lệnh mới dành cho CICAM để giải quyết một loại hoạt động dò kênh khác:

Kiểm soát máy chủ 2: Yêu cầu máy chủ dò kênh đế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ụ này chưa được máy chủ phát hiện trong quá trình phát hiện dịch vụ), dịch vụ này được lựa chọn dựa vào:

o Mô tả vật lý của dòng truyền tải mang dịch vụ

o Nhận dạng dịch vụ (ví dụ như service_id)

14.6.2. Các APDU của kiểm soát máy chủ DVB phiên bản 2

Tài nguyên kiểm soát máy chủ DVB phiên bản 2 hỗ trợ các đối tượng sau:

Bảng 14.28: Các APDU của kiểm soát máy chủ DVB phiên bản 2

Các APDU kiểm soát máy chủ phiên bản 2

ng

tune

CICAM à HOST

replace

CICAM à HOST

CIear_replace

CICAM à HOST

ask_release

CICAM ß HOST

tune_broadcast_req

CICAM à HOST

tune_reply

CICAM ß HOST

ask_release_reply

CICAM à HOST

14.6.2.1. tune_broadcast_req APDU

CICAM gửi APDU này để yêu cầu máy chủ dò kênh đến một dịch vụ dựa trên mô tả vật lý của dòng truyền tải mang dịch vụ và nhận dạng của dịch vụ này. Máy chủ trả lời bằng tune_reply () APDU.

Bảng 14.29 - Cú pháp tune_broadcast_req APDU

Cú pháp

S bit

Kiểu

tune_broadcast_req() {
tune_broadcast_req_tag length_field() reserved
pmt_flag service_id reserved
descriptor loop_length for (i=0; i<N; i++) {
descriptor()
}
if (pmt_flag==1) { program_map_section()
}
}


24

7
1
16
4
12


uimsbf

uimsbf
uimsbf
uimsbf
uimsbf
uimsbf

pmt_flag: pmt_flag là trường 1-bit chỉ ra khi tune_broadcast_req chứa một PMT. Giá trị "0" chỉ ra rằng yêu cầu này không chứa một PMT và rằng máy chủ phải lấy về PMT của service_id dịch vụ này từ dòng truyền tải. Giá trị "1" ch ra rằng yêu cầu này chứa một PMT mà máy chủ phải sử dụng để thực hiện lựa chọn dòng thành phần.

service_ld: trường 16-bit này được sử dụng làm nhãn để nhận dạng dịch vụ được yêu cầu này so với bất kỳ dịch vụ khác trong dòng truyền tải được dò kênh. Nó cũng giống như program_number trong PMT. Nếu service_id bằng không thì pmt_flag cũng phải bằng không và máy chủ phi dò kênh tần số này nhưng không phải lựa chọn một dịch vụ, một ca_pmt sẽ không được gửi đi.

descriptor_loop_length: trường 12-bit này chỉ ra tổng đ dài theo byte của vòng các nhãn mô tả tiếp theo.

descriptor (): nhãn mô tả này được mã hóa theo EN 300 468 dành cho thông tin dịch vụ (SI) trong hệ thống DVB [10]. Bảng 14.34 chỉ ra các nhãn mô tả có thể có sẵn trong vòng.

program_map_section (): bảng ánh xạ chương trình theo tiêu chuẩn ISO/IEC 13818-1.

14.6.2.2. tune_reply APDU

APDU này là trả lời của máy chủ đối với một tune_broadcast_req () hoặc tune () như được quy định tại điều 8.5.1.1 của EN 50221 [7]. Nó cung cấp cho CICAM trạng thái của yêu cầu dò kênh.

Bảng 14.30 - Cú pháp tune_reply APDU

Cú pháp

Số bit

Kiểu

tune_reply () {
tune_reply_tag
length_field()
status_field
}


24

8


uimsbf

uimsbf

status_field: trường 8-bit này xác định trạng thái dò kênh theo Bảng 14.31.

Bảng 14.31 - Các giá trị trạng thái tune_reply

status_field

Giá trị

Trạng thái OK-Dò kênh thành công (Xem CHÚ THÍCH 1)

0x00

Lỗi -Bộ mô tả hệ thống phân phối không được hỗ trợ

0x01

Lỗi -Bộ dò kện không khóa

0x02

Lỗi -Bộ dò kênh đang bận

0x03

Lỗi -Các tham s bị lỗi hoặc bị sót. (Xem CHÚ THÍCH 2)

0x04

Lỗi -Không tìm thấy dịch vụ

0x05

Lỗi -Không xác định

0x06

Dự phòng

0x07-0xFF

CHÚ THÍCH:

1: Theo sau một hoạt động dò kênh thành công, máy chủ phải trả lại một ca_pmt() tách t PMT có thể áp dụng được.

2: Nếu một bộ mô tả bắt buộc bị sót trong yêu cầu dò kênh, thì phải trả lại lỗi này. Các bộ mô tả bắt buộc được liệt kê trong Bảng Table 14.28

14.6.2.3. ask_release APDU

Kiểm soát máy chủ phiên bản 2 sử dụng ask_release () APDU này. Cú pháp của APDU này được quy định tại điều 8.5.1.4 của EN 50221 [7] và hành vi của nó bị thay đổi để cho phép CICAM nm quyền kiểm soát bộ dò kênh nếu được yêu cầu. CICAM có thể truy vấn người sử dụng để xác nhận hành động này. CICAM trả lời cho máy chủ trạng thái giải phóng bộ dò kênh bằng ask_release_reply APDU này.

14.6.2.4. ask_release_reply APDU

APDU này là trả lời của CICAM đối với một ask_release (). APDU này chỉ ra xem CICAM có xác nhận hay không khi bộ dò kênh phải được giải phóng và phiên này đóng.

Bảng 14.32 - Cú pháp Tune Release Reply APDU

Cú pháp

Số bit

Kiểu

ask_release_reply() {
ask_release_query_tag
length_field()
release reply
}


24

8


uimsbf

uimsbf

release_reply: trường 8-bit này chỉ ra trạng thái dò kênh theo Bảng 14.33

Bảng 14.33 - Các giá trị trả lời giải phóng bộ dò kênh

release_reply

Giá trị

Trả về OK - Máy chủ lấy lại quyền điều khiển bộ dò kênh

0x00

Trả lại bị từ chối - CICAM giữ lại quyền điều khiển bộ dò kênh

0x01

Dự phòng

0x02-0xFF

14.6.3. Quản PMT

Đối với triển khai video theo yêu cầu (VOD), thường là trong các mạng cáp thì các thành phần VOD được phân phối trên kênh truyền hình chỉ là các thành phần của dòng thành phần và kênh truyền hình này không cung cấp các thành phần PSI và SI. Trong trường hợp này thì PMT được CICAM cung cấp trong APDU và được xây dựng từ thông tin mà CICAM lấy được từ thiết bị đầu cuối, thường là thông qua tài nguyên truyền tc độ thấp.

Người tạo ra ứng dụng của bất kỳ ứng dụng VOD phải lưu ý rng trong trường hợp không có bất kỳ SI trong dòng thì hoạt động dò kênh này gây ra trễ 5 giây trong khi việc kiểm tra ngăn chặn máy chủ được thực hiện để có được SDTActual sẽ bị thất bại và hết thời gian chờ. Việc kiểm tra máy chủ này đối với SDT không thể bị vô hiệu vì điều này gây ảnh hưởng đến an ninh được máy chủ trên mạng tạo nên.

Khi CICAM yêu cầu dò kênh trên một kênh truyền hình, nó có thể cung cấp PMT của dịch vụ này trong APDU. APDU PMT này được máy chủ sử dụng và máy chủ không phi cố gắng để có được PAT hoặc PMT từ mạng phát sóng.

14.6.4. Nhãn mô tả

tune_broadcast_req () APDU chứa một vòng các nhãn mô tả được máy chủ sử dụng để cung cấp thông tin về dịch vụ được dò kênh này.

Khi CICAM yêu cầu máy chủ dò kênh bằng tune_broadcast_req () thì CICAM phải cung cấp cho máy chủ với một vị trí dò kênh duy nhất được một hoặc nhiều nhãn mô tả hệ thống cung cấp. Nếu vòng nhãn mô tả chứa nhiều hơn một vị trí dò kênh thì máy chủ phải xem xét vị trí đầu tiên và bỏ qua các vị trí còn lại.

CICAM có thể tùy chọn cung cấp cho máy chủ thêm thông tin về dịch vụ được yêu cu dò kênh. Thông tin được cung cấp có thể được máy chủ sử dụng để cung cấp cho người sử dụng mô tả của dịch vụ và sự kiện, ví dụ như để đưa các hội thoại thông tin và băng chương trình. Cơ chế chính xác mà máy chủ cung cấp thông tin này vào các ngăn xếp DVB của nó không được xác định và tùy thuộc vào thiết bị thu cụ thể, ví dụ như máy chủ có thể xây dựng một EITpf nội bộ với thông tin này dành cho dịch vụ hiện đang được chọn.

Bảng sau quy định danh sách các nhãn mô tả DVB có thể xuất hiện trong vòng nhãn mô tả của một yêu cầu dò kênh.

Bảng 14.34 - Các nhãn mô tả được cho phép trong tune_broadcast_req APDU

Descriptor

Giá trị thẻ DVB

Diễn giải

terrestrial_delivery_system_descriptor

0x5A

Một tần số đích duy nhất phải được xác định bởi bộ mô tả hệ thống phân phối phù hợp với mạng hiện thời.

T2_delivery_system_descriptor

0x7F, 0x04 Xem CHÚ THÍCH

satellite_delivery_system_descriptor

0x43

S2_satellite_delivery_system_descriptor

0x79

cable_delivery_system_descriptor

0x44

C2_delivery_system_descriptor

0x7F, 0x0D Xem CHÚ THÍCH

service_descriptor

0x48

Thông tin tùy chọn thêm vào cho máy thu mô tả dịch vụ.

short_event_descriptor

0x4D

component descriptor

0x50

parental_rating_descriptor

0x55

content_descriptor

0x54

CHÚ THÍCH: T2_delivery_system_descriptor và C2_deIivery_system_descriptor là các bộ mô t DVB mở rộng, xem EN 300 468 [10], điều 6.2.16 và điều 6.3.

14.6.5. Giao thức dò kênh máy chủ

Hình 14.10 cung cấp tổng quan về hành vi của máy chủ sau khi nhận được một yêu cầu dò kênh kiểm soát máy chủ DVB phiên bản 2.

Hình 14.10 - Quá trình dò kênh với kiểm soát máy chủ phiên bản 2

1) Máy chủ nhận được một tune_broadcast_req ()

2) Máy chủ kiểm tra tính sẵn sàng và tính nhất quán của các thông số này. Nếu một hoặc nhiều thông số này không phù hợp hoặc là thiếu thì máy chủ tiếp tục với bước 10

3) Máy chủ kiểm tra hệ thống cung cấp được hỗ trợ. Nếu nhãn mô tả của hệ thống cung cấp không được hỗ trợ thì máy chủ tiếp tục với bước 11

4) Máy chủ điều chnh bộ dò kênh qua dòng truyền ti được mô tả

5) Máy chủ xác nhận rằng hoạt động dò kênh này thành công và nhận được một tín hiệu hợp lệ. Nếu việc dò kênh thất bại thì máy chủ tiếp tục với bước 12

6) Máy chủ xác định xem một PMT đã được truyền trong yêu cầu này, nếu PMT không có thì PMT phải được lấy từ dòng truyền hình. Nếu PMT này không có sẵn thì máy chủ tiếp tục với bước 13.

7) Máy chủ gửi tune_reply () đến CICAM với trạng thái OK

8) Máy chủ sử dụng PMT này để chọn các dòng thành phần

9) Máy chủ gửi một ca_pmt () đến CICAM

10) Máy chủ gửi một tune_reply () với Error 04 (các thông số thiếu hoặc không phù hợp)

11) Máy chủ gửi một tune_reply () với Error 01 (nhãn mô tả của hệ thống cung cấp không được hỗ trợ)

12) Máy chủ gửi một tune_reply () với Error 02 (bộ dò kênh không khóa)

13) Nếu PMT này không có sẵn trong tune_broadcast_request máy chủ lấy PMT này từ dòng truyền tải được dò kênh này

14) Máy chủ kiểm tra xem PMT có được tải về thành công. Nếu PMT không được tải về thì máy chủ tiếp tục với bước 15

15) Máy chủ gửi một tune_reply () với Error 05 (dịch vụ này không tìm thấy)

14.6.6. Các yêu cầu giải phóng kiểm soát máy chủ

Khi một phiên được mở với tài nguyên kiểm soát máy chủ DVB và máy chủ phát hiện tương tác của người sử dụng dẫn đến việc dò kênh đến một dịch vụ khác, máy chủ phải xin phép CICAM để giải phóng bộ dò kênh này dành cho máy chủ sử dụng

Hình 14.11 cung cấp tổng quan về hành vi của máy chủ khi nó phát hiện tương tác của người sử dụng trong khi một phiên kiểm soát máy chủ DVB được mở.

1) CICAM đã mở một phiên với tài nguyên kiểm soát máy chủ DVB.

2) Máy chủ phát hiện tương tác của người sử dụng thường sẽ dẫn đến việc dò kênh đến một dịch vụ mới.

3) Máy chủ gửi một ask_release () đến CICAM để yêu cầu bộ dò kênh này được giải phóng.

4) Máy chủ nhận được một ask_release_reply () từ CICAM để trả lời truy vấn này.

5) Máy chủ kiểm tra xem CICAM có chấp nhận ask_release () này. Điều này có thể liên quan đến việc CICAM sử dụng MMI để truy vấn của người sử dụng. Nếu CICAM thừa nhận thì máy chủ tiếp tục với bước 6). Nếu CICAM không thừa nhận thì máy chủ trở về bước 1)

6) Máy chủ nhận được một phiên bị đóng từ CICAM.

7) Máy chủ dò kênh đến dịch vụ được người sử dụng lựa chọn.

Hình 14.11 - Quá trình dò kênh với kiểm soát máy chủ phiên bản 2

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

14.7.1. Giới thiệu

Các hồ sơ truyền hình trong phân khúc thị trường theo chiều dọc thường bị cản trở bởi việc triển khai các thiết bị thu độc quyền hiện có sử dụng tín hiệu riêng để truyền tải thông tin từ thiết bị đầu cuối đến thiết bị thu trong trường hợp này. Vì mạng này đã được thiết lập nên rất khó khăn cho các nhà điều hành dịch vụ thay đổi mạng lưới để phục vụ cho sự ra đời của các thiết bị thu của thị trường theo chiều ngang sử dụng giao diện chung không làm ảnh hưởng đến mạng lưới này và các thiết bị thu hiện có.

Các tín hiệu riêng trong các mạng này yêu cầu thiết bị thu của thị trường theo chiều ngang được thiết kế để nhận biết bất kỳ tín hiệu độc quyền trước khi chúng có thể được sử dụng trên mạng này. Việc phân tích các tín hiệu riêng này chỉ ra rằng tín hiệu độc quyền đa dạng nhất ở các cấp cao hơn trong hồ sơ mạng trong khi tín hiệu này ở cấp dịch vụ và cấp PSI nói chung là tuân thủ tín hiệu DVB chuẩn. Tín hiệu mạng cấp cao hơn thường bao gồm việc kiểm soát chặt chẽ danh sách kênh và đánh số kênh logic có thể được dựa vào, một phần, các quyền đăng ký và quyền sử dụng được người sử dụng mua.

Tài nguyên hồ sơ của nhà điều hành cố gắng giải quyết các vấn đề tương thích giữa mạng và thiết bị thu bằng cách cung cấp một hồ sơ truyền hình theo chuẩn CI Plus và sử dụng CICAM để phân tích tính hiệu riêng của mạng thành một cấu trúc thông tin thống nhất cho phép tất cả các thiết bị máy chủ CI Plus thực hiện cài đặt đầy đủ và lập một danh sách kênh của tt cả các dịch vụ theo yêu cầu của các nhà điều hành dịch vụ.

14.7.2. Tổng quan hoạt động

Tài nguyên hồ sơ của nhà điều hành cho phép cung cấp một bảng thông tin mạng (NIT) thông qua CICAM, bảng này được sử dụng trong ưu tiên hơn bất kỳ NIT của mạng truyền hình. Cơ chế cung cấp NIT này cho phép CICAM chuyển đổi thông tin mạng riêng và tín hiệu của nhà điều hành dịch vụ cụ thể sang một định dạng duy nhất được cung cấp trong một NIT mà tất cả thiết bị máy chủ CI Plus phù hợp tiêu chuẩn này nhận biết được.

Các nhà khai thác dịch vụ trong thị trường theo chiều dọc không có khả năng làm thay đổi đáng kể tín hiệu SI/PSI hiện có vì các thiết bị thu có thể đã được triển khai trong mạng. Tài nguyên hồ sơ nhà điều hành cung cấp một cơ chế dành cho tín hiệu SI cấp cao hơn được cu hình, đóng gói lại và cung cấp đến cho một máy chủ CI Plus nội bộ mà không ảnh hưởng đến tín hiệu truyền hình hiện có của mạng. Một cơ chế thông báo CICAM NIT cho phép SDT truyền hình được cấu hình lại một phần từ NIT này sử dụng ciplus_service_descriptor cung cấp việc kiểm soát hoàn toàn NIT. Một số điều chỉnh của PSI và EIT truyền hình trong mạng có thể được yêu cầu để cho phép tương thích hoàn toàn với một máy chủ CI Plus, điều này nói chung có nghĩa là tuân thủ đầy đủ hơn các tiêu chuẩn DVB. Hành vi hoạt động của mạng hiện tại có thể được cung cấp cho máy chủ thông qua operator_info () APDU trong đó xác định môi trường hoạt động này cho phép máy chủ đáp ứng các thay đổi hoạt động trong các mạng khác nhau.

Tài nguyên hồ sơ nhà điều hành cung cấp hai chế độ hoạt động khác nhau tùy thuộc vào profile_type được định nghĩa như sau:

• profile_type = 0 - hoạt động tiêu chuẩn (hoặc không định hình) theo DVB CI, trong đó mạng được xác định từ thông tin dịch vụ truyền hình. Thông tin thêm về hành vi mạng có thể xác định và truyền đến máy chủ trong tài nguyên này.

• profile_type = 1 - hoạt động định hình trong đó máy chủ xây dựng một danh sách kênh nội bộ một cách rõ ràng dành cho nhà điều hành dịch vụ và CICAM cung cấp một CICAM NIT thay thế cho máy chủ trong đó xác định mạng. Máy chủ không truy vấn mạng truyền hình này để xác định bảng sắp xếp kênh logic.

Hình 14.12 chỉ ra hoạt động của tài nguyên hồ sơ nhà đều hành khi chạy trong một chế độ cung cấp CICAM NIT.

Hình 14.12 - Hoạt động của tài nguyên hồ sơ nhà điều hành

Dòng truyền tải TS in truyền qua CICAM và được giải xáo trộn dưới sự kiểm soát máy chủ theo ca_pmt (). Thông tin dịch vụ (SI) của mạng tùy chọn được CICAM tách kênh và sử dụng để xây dựng CICAM NIT mới và được truyền đến máy chủ thông qua các operator_status ()operator_nit () APDU. Các bảng này được CICAM sử dụng để xây dựng CICAM NIT được nhà điều hành dịch vụ xác định và có thể được cung cấp từ các NIT, BAT, SDT của dòng truyền hình hoặc bất kỳ phần bảng riêng nào khác xuất hiện trên mạng. Các quyền sử dụng CAS/thẻ thông minh và service_type từ operator_search_start () APDU được sử dụng để xác định những dịch vụ nào có thể xuất hiện trong CICAM NIT. CICAM NIT là một cu trúc gần như tĩnh và được lưu trữ liên tục trong CICAM từ khi bảng này được xây dựng. Bảng này được CICAM duy trì bng cách giám sát mạng và các quyền sử dụng CAS/ thẻ thông minh và truyền bất kỳ thay đổi đến máy chủ bằng cách qun lý số phiên bản của CICAM NIT.

Máy chủ cung cấp một danh sách kênh đặc biệt dành cho từng hồ sơ CICAM được ghép với nó. Khi hoạt động với một danh sách kênh của một hồ sơ CICAM thì CICAM NIT này luôn luôn được sử dụng ưu tiên hơn bất kỳ NIT truyền hình nào. Thông tin CICAM NIT được sử dụng để xây dựng danh sách kênh này dành cho hồ sơ CICAM liên quan này. Những thay đổi trong hồ sơ này được gửi đến máy chủ bằng một operator_status () APDU không đồng bộ, trong đó chưa thông tin phiên bản của bất kỳ CICAM NIT được cập nhật với một số phiên bản của phần bảng mới và hoạt động giống như một phần bảng NIT được cập nhật trong một mạng truyền hình thông thưng.

CICAM NIT mô tả đầy đủ các dịch vụ xuất hiện trong danh sách kênh của nhà điều hành dịch vụ và thông tin đầy đủ có trong CICAM NIT cho phép máy chủ xây dựng một danh sách kênh đầy đủ. Máy chủ không được yêu cầu truy vn NIT, BAT hoặc SDT truyền hình để xây dựng, duy trì danh sách kênh và tất cả các thông tin này được cung cấp trong CICAM NIT. CICAM được yêu cầu xây dựng và duy trì CICAM NIT sử dụng thông tin danh sách kênh mới nhất, điều này có thể yêu cầu CICAM giám sát các bảng SI của mạng một cách chủ động.

Trong phạm vi của một h sơ CICAM thì có thể sử dụng Hướng dẫn chương trình điện t địa phương của máy chủ để hiển thị thông tin sự kiện chương trình của hồ sơ thu được thông qua thông tin EITsch từ mỗi bộ ghép kênh, thu được từ bộ ghép kênh tương tự khi truyền qua hoàn toàn hoặc thu được bởi việc dò kênh đến một kênh quảng cáo đặc biệt. EITsch có thể được cung cấp dưới dạng bị xáo trộn trên mạng.

CICAM và máy chủ phải tuân thủ hoàn toàn hồ sơ cá truyền hình được quy định tại Phụ lục N để đảm bảo tương thích hoàn toàn với tất cả các thiết bị CI Plus.

14.7.3. Xử lý hồ sơ nhà điều hành máy chủ

Tài nguyên hồ sơ nhà điều hành CICAM với một profile_type khác không yêu cầu máy chủ tạo ra một danh sách kênh logic riêng dành cho nhà điều hành dịch vụ với một nhãn được trường profile_name của operator_info () APDU mô tả. Máy chủ phải cung cấp một cơ chế lựa chọn để chuyển vào các danh sách kênh khác nhau như trong hình 14.13, trong đó CICAM đã thông báo một hồ sơ với tên hồ sơ là "CICAM network 1".

Hình 14.13 - Ví dụ một giao diện người sử dụng lựa chọn mạng

Tiêu chuẩn này không quy định cơ chế chính xác này của máy chủ để lựa chọn, thay đổi và cuối cùng là xóa các hồ sơ mạng khác nhau. Thủ tục cài đặt của một CICAM mới thông báo một hồ sơ nhà điều hành phải đơn giản đối với người sử dụng và máy chủ phi tự động khởi tạo và hướng dẫn người sử dụng thông qua thủ tục cài đặt này khi một CICAM mới với một hồ sơ có thể được hỗ trợ và đưa ra được ghép vào máy chủ.

Máy chủ phải giữ lại hồ sơ mạng này của CICAM cho đến khi cặp xác thực CI Plus CICAM bị g bỏ hoặc người sử dụng gỡ bỏ hồ sơ này. Máy chủ phải giữ lại hồ sơ này thông qua hoạt động gỡ bỏ CICAM cho phép một số lượng hạn chế các CICAM khác nhau được quay vòng mà không làm mất thông tin danh sách kênh được lưu trữ.

Thông tin hồ sơ nhà điều hành CICAM phải bao gồm một danh sách kênh logic độc lập giữ nguyên tín hiệu NIT của mạng CICAM này đối với profile_type 1. Máy chủ phải cung cấp một cơ chế bởi để di chuyển từ một hồ sơ nhà điều hành này sang một hồ sơ nhà điều hành khác.

14.7.4. Trao đổi tài nguyên hồ sơ nhà điều hành

Phần này mô tả việc trao đổi APDU giữa máy chủ và CICAM.

14.7.4.1. Khởi tạo

operator_status () APDU phải được CICAM tự động thông báo lúc khởi tạo và phải chứa thông tin hồ sơ được lưu trữ trong CICAM, thông tin này phải được cung cấp ngay lập tức. Nếu CICAM chưa được khởi tạo thì initialised_flag phải là "0", nếu CICAM yêu cầu một hoạt động dò kênh để thực hiện khởi tạo thì refresh_request_flag phải được thiết lập là "2" để chỉ ra rằng yêu cầu một hoạt động dò kênh ngay lập tức để khởi tạo CICAM.

14.7.4.1.1. CICAM không định hình

CICAM thông báo profile_type không (0) không hỗ trợ một danh sách kênh logic riêng và hoạt động như một DVB CICAM thông thường và được coi là không có một hồ sơ đặc biệt. Máy chủ nhận biết thông tin được truyền trên mạng và mạng này hoàn toàn tuân th DVB hoặc máy chủ đã được xây dựng đặc biệt để hoạt động với mạng này thì operator_info () APDU cung cấp một số thông tin cho máy chủ về môi trường mạng này.

Những cờ CICAM được phân tích theo một cách giống như một CICAM định hình và CICAM có thể yêu cầu dò kênh v.v.. điều này có thể được sử dụng để có được thông tin từ mạng và kiểm soát máy chủ. Thông thường CICAM bắt đầu trong trạng thái được khởi tạo vì không có thông tin bổ sung được truyền đến máy chủ.

14.7.4.1.2. CICAM định hình

CICAM thông báo profile_type một (1) yêu cầu máy chủ hỗ trợ một hồ sơ riêng và máy chủ tạo ra một danh sách kênh logic riêng dành cho nhà điều hành dịch vụ theo các quy tắc được nêu trong Phụ lục N.

Máy chủ phải tự động cài đặt hồ sơ này khi ghép CICAM và xây dựng danh sách kênh logic này với sự can thiệp của người sử dụng là tối thiểu. Hồ sơ và danh sách kênh kênh logic này phải được liên tục trong cả CICAM và máy chủ và không được tự động bị xóa khi CICAM hoặc thẻ thông minh được lấy ra tạm thời. Hồ sơ này nên được giữ lại cho đến khi người sử dụng xóa nó hoặc bất kỳ cặp xác thực CI Plus giữa CICAM và máy chủ bị g bỏ.

CICAM phải giữ lại thông tin hồ sơ này trong bộ nhớ liên tục (bao gồm cả CICAM NIT hoặc thông tin để xây dựng lại CICAM NIT). CICAM phải đảm bảo rằng cơ chế cập nhật bộ nhớ đệm là chắc chắn và có thể hỗ trợ hoạt động khi tắt điện ở bất kỳ giai đoạn nào trong hoạt động ghi mà không làm mất bất kỳ thông tin được lưu trữ hiện có cho đến khi thông tin mới đã được ghi hoàn toàn. Điều này tránh cho thông tin hồ sơ riêng không bị mất và ngẫu nhiên quay trở lại trạng thái chưa được khởi tạo.

14.7.4.1.3. Khôi phục hồ sơ

CICAM định hình có khả năng bắt đầu trong trạng thái chưa được khởi tạo và máy chủ được yêu cầu để xác định hệ thống cung cấp này của CICAM. Điều này có thể được xác định bằng cách truy vấn CICAM như trong hình 14.14.

Hình 14.14 - Trình tự APDU khôi phục hồ sơ

1. CICAM thông báo hồ sơ hiện tại khi mở phiên.

2. Máy chủ truy vấn CICAM về thông tin hồ sơ chung của nhà điều hành dịch vụ và mạng bằng cách sử dụng một operator_info_req () APDU.

3. CICAM thông báo thông tin hồ sơ này cho máy chủ trong operator_info () APDU. Số phiên bản của thông tin nhà điều hành được duy trì trong operator_status () APDU và máy chủ có thể phát hiện một thay đổi thông tin từ số phiên bản mà không cần truy vấn lại thông tin hồ sơ nhà điều hành một lần nữa.

4. Máy chủ cài đặt hồ sơ này, nếu hồ sơ chưa được khởi tạo thì khởi tạo việc tìm kiếm hồ sơ để tìm kiếm thông tin hồ sơ này bằng cách sử dụng operator_search_start () APDU.

5. Khi nhận được một operator_search_start () APDU thì CICAM phải điều khiển các hoạt động dò kênh của máy chủ và hiển thị trạng thái tìm kiếm đang diễn ra thông qua CICAM MMI. CICAM có thể yêu cầu có hoặc không có nhiều hoạt động dò kênh đến (các) bộ ghép kênh được yêu cầu bằng một operator_tune () APDU.

6. Khi nhận được một operator_tune () thì máy chủ dò kênh đến bộ ghép kênh được yêu cầu và thừa nhận sự dò kênh bằng một operator_tune_status () APDU chứa trạng thái dò kênh này. Nếu CICAM yêu cầu máy chủ tìm vị trí số tiếp theo thì CICAM có thể gửi một operator_tune () APDU khác thực hiện tìm kiếm kênh bằng cách sử dụng các vị trí được mô tả trong APDU này và được xác nhận bởi máy chủ bng một operator_tune_status () APDU khi việc tìm kiếm hoàn thành.

7. Khi CICAM đã hoàn thành việc tìm kiếm hồ sơ thì bất kỳ NIT nội bộ được cập nhật trên CICAM với thông tin mạng mới và phiên bản NIT này được cập nhật. operator_search_status () APDU được gửi và phải bao gồm trạng thái và mọi số phiên bản NIT mới. error_flag được thiết lập một cách thích hợp nếu system_descriptor của việc tìm kiếm không được hỗ trợ. Bất kỳ MMI ứng dụng hoặc cấp cao phải được loại bỏ trước khi operator_search_status () APDU được gửi đi.

8. Một CICAM profile_type = 0 có thể dừng ở đây. Nếu việc tìm kiếm hồ sơ không có lỗi thì máy chủ có thể cài đặt hồ sơ dựa trên thông tin CICAM NIT, máy chủ phải yêu cầu NIT sử dụng operator_nit_req () APDU.

9. CICAM phải trả về phiên bản mới nhất của NIT đến máy chủ bằng operator_nit () APDU.

Nếu hồ sơ không thể được CICAM tìm thy thì error_flag phải được thiết lập trong bất kỳ operator_status_body () để chỉ ra rằng hồ sơ nhà điều hành bị lỗi. error_flag dành cho việc tìm kiếm hồ sơ bị thất bại phải liên tục. error_flag này chỉ phải bị việc tìm kiếm nhà điều hành do máy chủ khởi tạo xóa hoặc thiết lập lại hoặc bằng một tương tác bên ngoài nào khác với CICAM ví dụ như các tùy chọn MMI để thiết lập lại hoặc sự phát hiện của CICAM rằng CICAM đã được tháo ra và ghép trở lại.

14.7.4.1.4. Các vn để khởi tạo

Tài nguyên hồ sơ nhà điều hành nên được tạo ra càng nhanh càng tốt từ khi được CICAM khởi tạo để cho máy chủ một cơ hội để bao gồm hồ sơ nhà điều hành trong bất kỳ thủ tục cài đặt. Một CICAM định hình nên thông báo sự hiện diện của một hồ sơ nhà điều hành trong thông tin CIS để thông báo cho máy chủ rằng một hồ sơ nhà điều hành là sẵn có và sau đó máy chủ có thể chờ đợi CICAM để tạo ra tài nguyên hồ sơ nhà điều hành trước khi tiến hành bất kỳ quá trình cài đặt.

Khi cài đặt lần đầu thì có khả năng là tài nguyên hồ sơ nhà điều hành nên được xử lý trước khi máy chủ và CICAM có thể kết nối vào mạng và sau đó lấy được thời gian và ngày. CICAM phải đảm bảo rằng bất kỳ thủ tục xác thực tài nguyên kiểm soát nội dung chỉ được bắt đầu khi CICAM và máy chủ đều đã lấy ngày và thời gian hợp lệ, tức là, tài nguyên hồ sơ nhà điều hành được xử lý trước bất kỳ việc thực hiện xác thực kiểm soát nội dung.

14.7.4.2. Chuyển đổi giữa hai hồ sơ

Yêu cầu máy chủ thông báo cho CICAM khi nó vào và rời khỏi môi trường profile_type 1. Máy chủ vào môi trường nhà điều hành bằng cách gửi một operator_status_req () APDU, CICAM có thể giả định rằng máy chủ đang chủ động chạy trong hồ sơ này cho đến khi một operator_exit () APDU nhận được. Khi vào môi trường hồ sơ nhà điều hành thì các hành vi sau đây được yêu cầu:

• CICAM phải chủ động duy trì môi trường hồ sơ nhà điều hành.

• CICAM có thể giả định rằng các dòng truyền tải truyền qua CICAM là một phần của môi trường hồ sơ nhà điều hành.

• Máy chủ phải duy trì môi trường hồ sơ này bằng cách sử dụng operator_status () APDU.

Máy chủ có thể rời khỏi một hồ sơ nhà điều hành vì một hồ sơ khác hoặc một trong các danh sách kênh riêng bất kỳ của nó. Khi máy chủ rời khỏi hồ sơ này, các hành vi sau đây được yêu cầu:

• CICAM không được giả định rằng các dòng truyền tải truyền qua CICAM là một phần của môi trường hồ sơ nhà điều hành.

• CICAM phải tiếp tục xử lý ca_pmt () và giải xáo trộn nội dung khi nó có thể.

• Không yêu cầu máy chủ duy trì môi trường hồ sơ này hoặc xử lý operator_status () APDU.

Máy chủ sau đó có thể quay trở lại môi trường hồ sơ nhà điều hành một lần nữa bằng cách gửi một operator_status_req () APDU. Trình tự APDU được mô tả trong hình 14.15.

Hình 14.15 - Vào và rời khỏi một môi trường định hình

Các hành vi của hệ thống được quy định như sau:

1. CICAM tự động thông báo profile_status () APDU khi khởi tạo.

2. Máy chủ chuyển vào môi trường hồ sơ nhà điều hành và gửi một operator_status_req () APDU.

3. CICAM đang được hoạt động trong môi trường nhà điều hành định hình và xác nhận cho máy chủ bằng một operator_status () APDU.

4. Máy chủ rời khỏi môi trường hồ sơ nhà điều hành bằng cách gửi một operator_exit () APDU, và có thể hoạt động trong một hồ sơ nhà điều hành khác hoặc với một hệ thống cung cấp khác bằng cách sử dụng một danh sách kênh khác.

5. Máy chủ chuyển trở lại môi trường nhà điều hành định hình và gửi một operator_status_req () APDU.

6. CICAM một lần nữa được hoạt động trong môi trường nhà điều hành định hình và xác nhận cho máy chủ bằng một operator_status () APDU.

14.7.4.3. Thay đổi quyền

entitlement_change_flag của operator_status_body () được thiết lập khi quyn CAS đã thay đổi. Sự thay đổi quyền có thể được thông báo khi người sử dụng cập nhật thuê bao của mình. Sự thay đổi thuê bao này có thể cho phép truy nhập nhiều hơn/ít hơn các dịch vụ và có thể yêu cầu một bản cập nhật vào danh sách kênh máy chủ. Khi phát hiện sự thay đổi quyền thì máy chủ phải thông báo cho người sử dụng rằng các quyền được hưng đã thay đổi, cập nhật danh sách kênh ở nhưng nơi cần thiết và sau đó xác nhận cho CICAM rằng quyền này đã được xử lý khi CICAM phải xóa cờ thay đổi quyền.

entitlement_change_flag phải được máy chủ xử lý càng nhanh càng tốt để cài đặt bất kỳ các dịch vụ mới tương ứng với sự thay đổi quyền. Điều này có thể yêu cầu thông báo cho người sử dụng rằng sự thay đổi quyền đã xảy ra và sau đó ngay lập tức chuyển việc kiểm soát dò kênh cho CICAM để có được các thay đổi của bảng sắp xếp dịch vụ từ mạng.

Các trạng thái cờ của operator_status_body () chỉ ra cách máy chủ nên xử lý sự thay đổi quyền.

14.7.4.3.1. Thay đổi quyền đơn giản

Trong trường hợp đơn giản, thì quyền được cập nhật, nó có thể dẫn đến một sự thay đổi đối với bảng CICAM NIT. Máy chủ cập nhật danh sách kênh với bất kỳ thay đổi CICAM NIT và sau đó xác nhận cho CICAM rằng quyền này đã được xử lý. Sự trao đổi APDU được thể hiện trong hình 14.16.

Hình 14.16 - Trình tự APDU thay đổi quyền đơn giản

Các hành vi của hệ thống được mô tả như sau:

1. CICAM phát hiện sự thay đổi quyền được hưởng và cập nhật NIT nếu cần. Sự thay đổi này được thông báo trong một operator_status () APDU với trường entitlement_pending_flag được thiết lập. refresh_request_flag có thể chưa được thiết lập chỉ ra rằng CICAM đã nhận biết được sự thay đổi quyền và NIT đã sẵn sàng, không yêu cầu tìm kiếm.

2. Máy chủ thông báo cho người sử dụng về sự thay đổi quyền và chuẩn bị để cập nhật danh sách kênh nếu CICAM NIT đã thay đổi (điều này có thể yêu cầu sự cho phép của người sử dụng để xử lý sự thay đổi quyền ngay lập tức).

3. Nếu NIT đã thay đổi, được thể hiện qua số phiên bản được cập nhật thì máy chủ yêu cầu CICAM NIT mới từ CICAM.

4. CICAM gửi CICAM NIT mới đến máy chủ. Khi máy chủ đã xử lý CICAM NIT này và cập nhật danh sách kênh thì sự thay đổi được xác nhận cho CICAM bằng cách gửi một operator_entitlement_ack ().

5. Khi nhận được một operator_entitlement_ack () để xóa yêu cầu về quyền thì CICAM xóa entitlement_change_flag và xác nhận sự thay đổi của trạng thái bằng một operator_status () APDU mới.

Lưu ý rằng CICAM có thể không yêu cầu sự cập nhật cho CICAM NIT và CICAM có thể thông báo sự thay đổi quyn mà không cn cập nhật phiên bản CICAM NIT. Yêu cầu máy chủ thông báo cho người sử dụng rằng quyền đã được thay đổi và sau đó xác nhận cho CICAM rằng người sử dụng đã được thông báo về sự thay đổi quyền.

14.7.4.3.2. Thay đổi quyền có yêu cầu tìm kiếm

Sự thay đổi quyền đôi khi có thể yêu cầu CICAM tìm kiếm trên mạng để có được sự thay đổi bảng sắp xếp dịch vụ mới, trong trường hợp này CICAM có thể thông báo sự thay đổi quyền này bằng yêu cầu làm mới lại trong cùng APDU, tức là entitlement_change_flag = 1 và refresh_request_flag = 1. Nếu hoạt động dò kênh là cấp thiết thì CICAM có thể thông báo refresh_request_flag = 2 chỉ ra rằng quyền này không th được xử lý cho đến khi máy chủ đã gửi tìm kiếm. Việc trao đổi APDU được th hiện trong hình 14.17.

Hình 14.17 - Trình tự APDU thay đổi quyền tìm kiếm

Các hành vi của hệ thống được mô tả như sau:

1. CICAM phát hiện sự thay đổi quyền được hưng nhưng không có khả năng xác định liệu danh sách kênh có bị sự thay đổi này làm thay đổi mà không cần quét mạng. Sự thay đổi này được thông báo trong một operator_status () APDU và entitlement_pending_flag được thiết lập và refresh_request_flagis thiết lập là 1 hoặc 2 tùy thuộc vào tính cấp thiết của việc tìm kiếm mạng.

2. Máy chủ thông báo cho người sử dụng về sự thay đổi quyền, nếu refresh_request_flag được thiết lập là 1 thì có thể cho người sử dụng một tùy chọn để xử lý sự thay đổi quyền này ngay lập tức, khi refresh_request_flag là 2 thì việc yêu cầu truy vấn mạng là cấp thiết hơn thì có thể không cho người sử dụng bất kỳ tùy chọn để cài đặt sau đó. Khi máy chủ đã sẵn sàng để xử lý sự thay đổi quyền thì việc tìm kiếm được khởi tạo để bắt đầu quét mạng và một operator_search_start () APDU được gửi và việc kiểm soát chuyển đến cho CICAM.

3. Khi nhận được một operator_search_start () thì CICAM có thể yêu cầu một hoặc nhiều hoạt động dò kênh đối với (các) bộ ghép kênh bằng một operator_tune () APDU. Trong một chế độ có máy chủ tham gia thì CICAM phải duy trì sự thông báo cho người sử dụng về tiến độ bằng cách sử dụng MMI ứng dụng hoặc cấp cao.

4. Khi nhận được một operator_tune () thì máy chủ dò kênh đến bộ ghép kênh được yêu cầu và xác nhận sự dò kênh bằng một operator_tune_status () APDU có chứa trạng thái của yêu cầu dò kênh.

5. Khi CICAM đã hoàn thành việc tìm kiếm thì bất kỳ NIT được lưu trữ được cập nhật với thông tin mạng mới, số phiên bản được cập nhật và một operator_search_status () APDU được gửi đến máy chủ. Trường entitlement_change_flag vẫn phải được thiết lập vì sự thay đổi quyền này đã không được máy chủ xác nhận. Bất kỳ MMI ứng dụng hoặc cấp cao phải được gỡ bỏ trước khi gửi trạng thái tìm kiếm.

6. Khi nhận được operator_search_status () APDU máy chủ xác định xem NIT đã thay đổi bằng cách sử dụng trường nit_version. Nếu phiên bản NIT đã được cập nhật thì máy chủ có thể yêu cầu CICAM NIT mới bằng cách sử dụng operator_nit_req () APDU.

7. CICAM trả về NIT được cập nhật cho máy chủ bằng operator_nit () APDU và máy chủ cập nhật danh sách kênh nếu CICAM NIT đã thay đổi.

8. Khi danh sách kênh đã được cập nhật thì sự thay đổi quyền được xác nhận đến CICAM bằng cách gửi một operator_entitlement_ack () APDU.

9. Khi nhận được một operator_entitlement_ack () để xóa yêu cầu về quyền thì CICAM xóa entitlement_change_flag và xác nhận sự thay đổi của trạng thái bằng một operator_status () APDU mới.

14.7.4.4. Dò kênh và quét

Có một số kịch bản dò kênh và quét khác nhau được hồ sơ nhà điều hành yêu cầu, tất cả các kịch bản dò kênh được máy chủ khởi tạo một cách rõ ràng bằng cách sử dụng operator_search_start () APDU. Máy chủ có thể lựa chọn để khởi tạo một trình tự dò kênh khi:

• CICAM yêu cầu dò kênh bằng refresh_request_flag trong operator_status_body () của một APDU của hồ sơ nhà điều hành.

• Máy chủ tìm kiếm không theo yêu cầu, thường là một phần của việc bảo trì mạng của thiết bị thu của máy chủ được thực hiện trong trạng thái chờ, v.v..

Máy chủ nên cung cấp cho CICAM cơ hội để tự cập nhật mạng ít nhất hàng tuần như là một phần của bất kỳ chu kỳ bảo trì được máy chủ khởi tạo bằng cách khởi tạo một hoạt động tìm kiếm không theo yêu cầu. CICAM có thể thông báo một ngày và thời gian để thực hiện việc quét nền bằng cách sử dụng một yêu cầu làm mới theo một chu kỳ thời gian.

CICAM có khả năng thông báo cho máy chủ rằng nó yêu cầu dò kênh bằng cách sử dụng refresh_request_flag trong thành phần operator_status_body () của một APDU. Tính cấp thiết của yêu cầu dò kênh được xác định từ trạng thái của trường này.

• cảnh báo nâng cao (1) thông báo cho máy chủ rằng yêu cầu dò kênh trong tương lai gần. Thông báo này không nên ảnh hưởng đến người sử dụng và phải được sử dụng tại thời điểm thích hợp tiếp theo của máy chủ, nghĩa là khi việc quét nền trở lại khi người sử dụng ở trạng thái chờ, v.v...

• yêu cầu cấp thiết (2) thông báo cho máy chủ rằng yêu cầu dò kênh ngay lập tức. Điều này chỉ được CICAM thông báo trong các trường hợp trong đó một số phận của mạng không thể truy nhập cho đến khi dò kênh được thực hiện. Máy chủ nên khởi tạo dò kênh ngay lập tức sau khi có sự xác nhận từ người sử dụng.

• yêu cầu có chu kỳ thời gian (3) thông báo cho máy chủ rằng yêu cầu tìm kiếm theo lịch trình tại một thời gian và ngày trong tương lai. Máy chủ phải thực hiện tìm kiếm theo lịch trình nếu nó có thể (tức là không được tắt nguồn điện). Nếu tìm kiếm đã bị bỏ l thì CICAM không cần thiết phải yêu cầu máy chủ thực hiện quét ngay lập tức nhưng nên lập lịch trình lại vào một ngày sau đó. Điều này tránh làm gián đoạn không cần thiết đối với người sử dụng.

Hoạt động dò kênh được coi là cấp thiết hơn nếu entitlement_pending_flag được thiết lập cùng với refresh_request_flag để chỉ ra rằng các quyền được hưởng đã được cập nhật và yêu cầu hoạt động dò kênh để đánh giá lại quyền đó.Trong trường hợp này, máy chủ có thể lựa chọn để thông báo cho người sử dụng sự thay đổi quyền và yêu cầu sự cho phép để khởi tạo việc tìm kiếm ngay lập tức để đánh giá lại mạng.

refresh_request_flag có thể được thiết lập và xóa như là một phần của hoạt động bình thường của hệ thống (tức là khi người sử dụng đang theo dõi một dịch vụ) vì thông tin nhận được từ bộ ghép kênh hiện tại có thể gây ra một yêu cầu chờ được thêm vào hoặc gỡ bỏ khi thông tin cập nhật nhận được từ mạng.

14.7.4.4.1. Tìm kiếm hồ sơ

Việc trao đổi APDU để tìm kiếm hồ sơ được th hiện trong hình 14.18.

Hình 14.18 - Trình tự APDU tìm kiếm hồ sơ

Các hành vi của hệ thống được mô tả như sau:

1. CICAM tùy chọn phát hiện sự thay đổi của mạng mà yêu cầu CICAM thực hiện một hoạt động tìm kiếm. Mức ưu tiên của yêu cầu tìm kiếm được xác định và refresh_request_flag được thiết lập đến một giá trị thích hợp với mức ưu tiên tìm kiếm. Sự thay đổi này được thông báo trong một operator_status () APDU và refresh_request_flagis thiết lập một giá trị khác không phụ thuộc vào tính cấp thiết của việc dò kênh.

2. Khi máy chủ đã sẵn sàng để xử lý việc tìm kiếm hồ sơ thì operator_search_start () APDU được gửi đến CICAM và việc kiểm soát của dò kênh và MMI được chuyển sang CICAM.

3. Khi nhận được một operator_search_start () với tìm kiếm hồ sơ thì CICAM yêu cầu một hoặc nhiều hoạt động dò kênh đối với (các) bộ ghép kênh được bằng một operator_tune () APDU. Quá trình của việc tìm kiếm phải được truyền đến người sử dụng bằng cách sử dụng MMI ứng dụng hoặc cấp cao trong đó có sự tham gia của máy chủ.

4. Khi nhận được một operator_tune () APDU thì máy chủ dò kênh đến bộ ghép kênh được yêu cầu và xác nhận dò kênh bằng một operator_tune_status () APDU có chứa trạng thái của dò kênh.

5. Khi CICAM đã hoàn thành việc tìm kiếm hồ sơ thì bất kỳ NIT trong CICAM được cập nhật với thông tin mạng mới, phiên bản CICAM NIT được cập nhật và operator_search_status () APDU được gửi đến máy chủ. refresh_request_flag được thiết lập lại. Bất kỳ MMI ứng dụng hoặc cấp cao phải được gỡ bỏ.

6. Nếu phiên bn NIT đã thay đổi trong operator_status_body () thì máy chủ có thể yêu cầu bảng CICAM NIT mới bằng operator_nit_req () APDU.

7. Khi nhận được operator_nit_req () APDU thì CICAM trả về các phần CICAM NIT được lưu trữ mới nhất cho máy chủ trong một operator_nit () APDU. Máy chủ có thể sử dụng CICAM NIT để cập nhật danh sách kênh.

14.7.4.4.2. Các yêu cầu dò kênh

CICAM chỉ có thể khởi tạo một yêu cầu dò kênh operator_tune () APDU để đáp ứng operator_search_start () APDU của máy chủ. Khi việc tìm kiếm đã được khởi tạo thì CICAM được phép khởi tạo nhiều yêu cầu dò kênh. Hoạt động dò kênh này có thể:

• chuyển đến một vị trí hệ thống cung cấp rõ ràng.

• yêu cầu máy chủ để thực hiện dò kênh quét dựa trên một danh sách các vị trí hệ thống cung cấp.

Việc dò kênh rõ ràng này yêu cầu máy chủ chuyển bộ dò kênh đến vị trí được delivery_system_descriptor xác định, không yêu cầu máy chủ lựa chọn bất kỳ dịch vụ trên bộ ghép kênh này. Nhiều vị trí dò kênh có thể được quy định và máy chủ phải xử lý các vị trí tuần tự theo thứ tự được quy định trong APDU này cho đến khi một tín hiệu hợp lệ được tìm thấy khi nó hoàn thành yêu cầu dò kênh này.

Trong trường hợp CICAM tìm kiếm thì máy chủ phải cho phép CICAM sử dụng các APDU khác để có được các thông tin bao gồm, nhưng không loại trừ, tài nguyên truyền tốc độ thấp. CICAM phải đảm bảo rằng các APDU khác mở ra trong trường hợp tìm kiếm này được đóng lại trước khi việc tìm kiếm này hoàn thành. CICAM không được phép sử dụng APDU nâng cấp phần mềm trong trường hợp tìm kiếm này.

Lệnh operator_tune () APDU cũng có thể được CICAM sử dụng để khôi phục dịch vụ và yêu cầu máy chủ quét mạng liên tục bằng cách sử dụng các nhãn mô tả hệ thống cung cấp để tìm một vị trí chứa tín hiệu. Lệnh này của máy chủ hoàn thành khi tín hiệu được tìm thấy hoặc đến cuối danh sách. Máy chủ trả về thông tin của vị trí được dò kênh đến CICAM. Thông tin này được máy chủ trả về trong bất kỳ phần định nghĩa của nhãn mô tả hệ thống cung cấp phải chính là thông tin có thể được sử dụng để xây dựng CICAM NIT.

Máy chủ hoàn thành một yêu cầu chạy dò kênh bằng cách gửi một operator_tune_status () APDU đến CICAM chứa thông tin về trạng thái hoạt động dò kênh. Máy chủ phải trả về một delivery_system_descriptor phải được gửi một cách đầy đủ và chính xác, mô tả vị trí được dò kênh hiện tại, một số giá trị của system_delivery_descriptor có thể được cung cấp từ thông tin thông báo tham số dò kênh được truyền trong tín hiệu thực tế. Thông tin cường độ và chất lượng tín hiệu từ giao diện mạng phi được bao gồm trong APDU này theo các giá trị tương đối phần trăm mà không nên được CICAM phân tích theo nghĩa tuyệt đối. Máy chủ không phải thông báo các tín hiệu sẵn có không khả thi đến CICAM, máy chủ có thể thông báo một vị trí tn số nơi mà tín hiệu dữ liệu được giao diện mạng này phát hiện nhưng tín hiệu này không chứa một dòng truyền tải hợp lệ, tức là không yêu cầu máy chủ phải xác định rằng tín hiệu này thực tế mang một dòng truyền tải hợp lệ.

Trong hoạt động dò kênh thì CICAM phải chắc chắn chống lại được những dao động của dữ liệu và tạp âm trên bus truyền dòng truyền tải. Máy chủ có thể lựa chọn, nhưng không bắt buộc, ngắt kết nối giao diện dòng truyền tải trong thời gian của hoạt động dò kênh để tăng thêm sự chắc chắn của hệ thống. Trong trường hợp dòng truyền ti bị máy chủ ngắt kết nối trong suốt thời gian dò kênh thì nó phải được nối lại trước khi gửi operator_tune_status () APDU đến CICAM.

14.7.4.4.3. Vấn đề nâng cấp CAM

Trình tự APDU nâng cấp phần mềm CICAM không được bắt đầu giữa một trình tự operator_search_start () cho đến khi CICAM trả về xác nhận operator_search_status () cuối cùng.

Trường hợp máy chủ khởi tạo tìm kiếm bảo trì định kỳ trong một chế độ chờ, trong đó máy chủ không tham gia, thì yêu cầu máy chủ cung cấp cho CICAM một cơ hội để đưa ra các yêu cầu thêm cho máy chủ. Khoảng thời gian 30 giây sau khi nhận được xác nhận operator_search_status () phải được máy chủ cung cấp để cho phép CICAM đủ thời gian để khởi tạo một yêu cầu APDU nâng cấp phần mềm trước khi máy chủ trở về với bất kỳ chế độ chờ sâu hơn.

14.7.5. Tài nguyên hồ sơ nhà điều hành

Tài nguyên hồ sơ nhà điều hành cho phép CICAM phối hợp quản lý hồ sơ này với máy chủ. Các bản tin này cho phép CICAM có được và duy trì các thông tin hồ sơ nhà điều hành với một số thỏa thuận từ thiết bị máy chủ. Thông báo những thay đổi môi trường nhà điều hành cho máy chủ bao gồm cả những thay đổi trong bảng sắp xếp dịch vụ và máy chủ được thông báo khi CICAM cần tìm kiếm trên mạng để có được các thông tin mới nhất. CICAM được cung cấp phương tiện để dò kênh và quét mạng để có được thông tin mạng được máy chủ hỗ trợ.

14.7.5.1. Các APDU tài nguyên hồ sơ nhà điều hành

CICAM mở tài nguyên operator_profile ngay từ khởi tạo và tài nguyên này vẫn mở để cung cấp bất kỳ thay đổi sau đó đối với thông tin hồ sơ này.

Bảng 14.35 - Các APDU hồ sơ nhà điều hành

1

Chiều

Mô tả

operator_status_req

HOST=>CICAM

Nhập vào hồ sơ profile và/ hoặc yêu cầu thông tin hồ sơ hiện thời.

operator_status

CICAM=>HOST

Thông tin trạng thái hồ sơ hiện thời.

operator_nit_req

HOST=>CICAM

Yêu cầu các phần CICAM NIT hiện thời.

operator_nit

CICAM=>HOST

Các phần CICAM NIT hiện thời.

operator_info_req

HOST=>CICAM

Yêu cầu thông tin nhà khai thác.

operator_info

CICAM=>HOST

Thông tin nhà khai thác.

operator_search_start

HOST=>CICAM

Máy chủ cho phép khởi đầu việc tìm mạng.

operator_search_status

CICAM=>HOST

CICAM thông báo rằng việc tìm mạng đã hoàn thành.

operator_exit

HOST=>CICAM

Máy chủ đã để lại hồ sơ nhà khai thác dịch vụ.

operator_tune

CICAM=>HOST

Yêu cầu chỉnh kênh tới một vị trí ghép cụ thể.

operator_tune_status

HOST=>CICAM

Yêu cầu dò kênh của máy chủ đã hoàn thành.

operator_entitlement_ack

HOST=>CICAM

Xác nhận rằng việc thay đổi quyền đã được thực thi.

14.7.5.2. operator_status_req APDU

Máy chủ gửi APDU này cho CICAM khi vào hồ sơ nhà điều hành dịch vụ và truy vấn trạng thái hồ sơ nhà điều hành hiện tại. CICAM trả lời bằng một operator_status () APDU. Khi CICAM nhận được operator_status_req () thì nó có thể giả định rằng máy chủ đang hoạt động trong phạm vi hồ sơ nhà điều hành này cho đến thời điểm nhận được một operator_exit () APDU khi không có thêm APDU bản cập nhật hồ sơ nhà điều hành không đồng bộ có thể tiếp tục được thông báo cho máy chủ cho đến thời điểm mà máy chủ vào lại hồ sơ này một ln nữa bằng một operator_status_req () APDU.

Bảng 14.36 - Cú pháp operator_status_req APDU

Cú pháp

Số bit

Kiểu

operator_status_req() {
operator_status_req_tag
length_field()
}


24


uimsbf

Trong đó các trường được quy định như sau:

operator_status_req_tag: Xem bảng L.1 tại Phụ lục L.

14.7.5.3. operator_status APDU

APDU này được CICAM gửi để thông báo cho máy chủ về các thiết lập hồ sơ nhà điều hành hiện tại của CICAM. Nó được gửi để trả lời một operator_status_req () APDU từ máy chủ. CICAM cũng gửi APDU này không đồng bộ lúc khởi tạo hoặc khi có sự thay đổi trong hồ sơ nhà điều hành phải được máy chủ ban hành.

Khi mở tài nguyên hồ sơ nhà điều hành CICAM gửi một operator_status () APDU đến máy chủ để truyền các thiết lập hồ sơ hiện tại.

Bảng 14.37 - Cú pháp operator_status APDU

Cú pháp

Số bit

Kiểu

operator_status () {
operator_status_tag
length_field()
operator_status_body()
}


24


uimsbf

Trong đó operator_status_body () được xác định theo quy định tại Bảng 14.38. Các operator_status_body () truyền tải thông tin về trạng thái của hệ thống CA khi dịch vụ CA được điều khiển bởi CICAM. Các operator_status_body () chứa các cờ và giá trị mà có thể làm cho máy chủ thực hiện một số hành động. Như một quy định chung, máy chủ và CICAM phải thống nhất với các loại hình dịch vụ đang được chọn như sau:

• Dịch vụ Free-to-air

o CICAM sẽ không thay đổi các thiết lập của cờ refresh_request_flag sang khẩn cấp.

o Máy chủ không nhất thiết phải gián đoạn hoặc ngăn chặn người dùng đang xem từ các dịch vụ hiện tại. Máy chủ sẽ xử lý bất kỳ yêu cầu nào có tính thời gian cấp bách hoặc thời gian hết hạn vào thời điểm sớm nhất sau khi người dùng không sử dụng dịch vụ để không làm gián đoạn dịch vụ hiện tại. Máy chủ có thể chọn thông báo cho người dùng rằng hệ thống CA yêu cầu một số thao tác và cho phép người sử dụng ra quyết định xem hoạt động này có thể được thực hiện ngay lập tức hoặc phải hoãn lại. Bất kỳ thao tác nào, khẩn cấp hoặc không có thể được hoãn lại để tránh bị gián đoạn người xem ví dụ hoãn lại cho đến khi người dùng chuyển kênh khác.

• Hồ sơ khai thác CICAM không làm chủ một dịch vụ CA - Như là dịch vụ Free-to-air.

• Hồ sơ khai thác CICAM làm chủ một dịch vụ CA

o CICAM có thể thay đổi các cờ resfresh_request_flag sang thiết lập bất kỳ bao gồm cả khn cấp.

o Máy chủ sẽ phải thực hiện thay đổi c refresh_request_flag sang khẩn cấp ngay lập tức, điều này có thể làm gián đoạn việc xem các dịch vụ hiện tại. Một thiết lập cờ refresh_request_flag sang khẩn cấp phải được thực hiện ngay lập tức trong sự lựa chọn của dịch vụ CA.

Bảng 14.38 - Cú pháp operator_status_body

Cú pháp

Số bit

Kiểu

operator_status_body() {
info_version
nit_version
profile_type
initialised_flag
entitlement_change_flag


3
5
2
1
1


uimsbf
uimsbf
uimsbf
bslbf
bslbf

entitlement_valid_flag
reserved
refresh_request_flag
error_flag
delivery_system_hint
refresh_request_date
refresh_request_time
}

1
1
2
4
4
16
8

bslbf
bslbf
uimsbf
uimsbf
bslbf
uimsbf
uimsbf

Trong đó các trường được quy định như sau:

operator_status_tag: Xem bảng L.1 tại Phụ lục L.

info_version: trường 3-bit này là một nhãn định danh duy nhất xác định phiên bản của thông tin hồ sơ được chứa trong operator_info () APDU. Phiên bản thông tin hồ sơ phải được tăng thêm 1, quay về 0, khi thông tin hồ sơ này thay đổi và yêu cầu máy chủ đánh giá lại nơi chứa hồ sơ. Phiên bản thông tin hồ sơ này chỉ được tăng lên khi có những thay đổi hồ sơ lớn bao gồm sự thay đổi tên hồ sơ, thay đổi loại hồ sơ v.v.. Nó không được tăng lên khi có sự thay đổi nit_version hoặc bất kỳ thay đổi trong trạng thái cờ.

nit_version: trường 5-bit này chỉ được phân tích trong phạm vi của một hồ sơ khác không và được thiết lập là số phiên bản hiện tại của NIT được CICAM cung cấp. Nếu CICAM không cung cấp một NIT thì trường này phải là không và không được máy chủ phân tích.

profile_type: trường 2-bit này xác định loại của hồ sơ CICAM, các hồ sơ CICAM được xác định trong Bảng 14.38.

Bảng 14.39 - Các giá trị profile_type

Giá trị

Mô tả

0

CICAM không hỗ trợ bất kỳ hồ sơ nào và tách các dòng tín hiệu cơ sở cho tng DVBCI

1

Hồ sơ là một mạng cá nhân sử dụng một CICAMNIT và có danh sách kênh logic hồ sơ cá nhân.

2-3

Dự phòng.

initialised_flag: trường 1-bit này chứa trạng thái khởi tạo hồ sơ dành cho hồ sơ cụ thể. Giá trị “0" chỉ ra rằng hồ sơ đã không được khởi tạo, một giá trị "1" chỉ ra rằng hồ sơ đã được CICAM khởi tạo.

entitlement_change_flag: trường 1-bit này phải được thiết lập khi sự thay đổi quyền đã xảy ra mà không được máy chủ xác nhận. Giá bị "0", mặc định, chỉ ra không có sự thay đổi quyền bị treo, giá trị "1" chỉ ra rằng sự thay đổi quyền chưa được xác nhận bị treo.

entitlement_valid_flag: trường 1-bit này được thiết lập khi quyền này là hợp lệ, trường này được quy định chỉ để tham khảo. Giá trị của "1", chỉ ra rằng quyền được hưởng đã có và hợp lệ. Giá trị "0" chỉ ra rằng không có quyền được hưng.

refresh_request_flag: trường 2-bit này phải được thiết lập khi CICAM yêu cầu hoạt động dò kênh để đi đến bộ ghép kênh khác để có được thêm thông tin về hồ sơ hoặc để kiểm tra quyền được hưởng, v.v..

Bảng 14.40 - Các giá trị refresh_request_flag

Giá trị

Mô tả

0

Trạng thái mặc định, cho biết rng CICAM không cần tham vấn mạng và đã được cập nhật.

1

Cảnh báo trước cho máy chủ rằng có gì đó trong mạng đã thay đổi và CICAM yêu cầu máy chủ điều chỉnh để thực hiện việc kiểm tra cập nhật khi thuận tiện. Yêu cầu này phải được trì hoãn cho đến khi máy chủ sẵn sàng thực hiện việc tìm kiếm mà không làm gián đoạn người sử dụng.

2

Yêu cầu khn từ CICAM rằng mạng cần phải được tham vấn đ thu thập thông tin. Một yêu cầu khẩn chỉ được báo hiệu khi CICAM không có đủ khả năng hoạt động cho tới khi mạng được tham vấn. Máy chủ phải khởi đầu việc tìm hồ sơ ngay khi có thể. Một máy chủ trong dịch vụ Free-to-air hay dịch vụ CA mà không gắn với CICAM sở hữu hồ sơ nhà khai thác thì không được yêu cầu xử lý cờ này ngay lập tức khi đang xử lý yêu cầu khác. Điều này sẽ làm gián đoạn hoặc ngăn chặn người dùng đang xem các dịch vụ hiện tại.

3

Yêu cầu nạp lại đã được lên kế hoạch từ CICAM rằng mạng cần phải được tham vấn tại một thời điểm cập nhật cụ thể. Máy chủ phải khởi đầu việc tìm hồ sơ tại thời điểm đó nếu có thể hoặc sau thời điểm đó. Điều này có thể yêu cầu máy chủ tự động bật từ chế độ chờ tại một thời điểm đã xác định để khởi động việc tìm kiếm. Nếu khe thời gian tìm kiếm bị lọt, ví dụ nếu máy thu bị tắt nguồn điện, thì CICAM nên lên kế hoạch lại vào một thời điểm khác thay vì bắt buộc máy chủ thực hiện việc tìm kiếm không cần thiết.

Việc làm mới kế hoạch đòi hỏi máy chủ phải gọi trình tìm kiếm nhà khai thác càng sớm càng tốt sau khi sự kiện này đã hết hạn. Khi trình tìm kiếm thông tin nhà điều hành được gọi bởi máy chủ thì CICAM có thể thực hiện tìm kiếm và/hoặc sắp xếp lại một tìm kiếm khác trong một thời gian/ngày sau đó bằng cách cập nhật các trường yêu cầu làm mới.

The state of the refresh_request_flag (and time/date) shall be updated by the CICAM to reflect the next refresh state required by the CICAM on completion of any operator search operation. The Host is notified of the new refresh request flag setting in addition to the other flags of the operator_status_body() in the operator_search_status () APDU.

error_flag: trường này là một trưng cờ 4-bit, chứa trạng thái của hồ sơ đang hoạt động hiện tại. Các bit của trường này được quy định theo Bảng 14.41.

Bảng 14.41 - Các giá trị error_flag

Giá trị

Mô tả

0

Không có lỗi.

1

Lỗi hồ sơ. CICAM đã gặp một lỗi và không thể lấy được hồ sơ, không có thông tin hồ sơ nào được lưu trữ.

2

Hệ thống phân phối không được hỗ trợ. CICAM không hỗ trợ (các) bộ mô tả hệ thống phân phối mà máy chủ báo cáo.

3

Bị hy bỏ. Tìm kiếm nhà khai thác đã bị gián đoạn và không hoàn thành

4-15

Dự phòng.

delivery_system_hint: trường này là một trường 4-bit, chứa một gợi ý của hệ thống cung cấp được hồ sơ nhà điều hành hỗ trợ và cung cấp cho máy chủ một đánh giá hồ sơ CICAM. Các bit của trường này nên được thiết lập theo Bảng 14.42.

Bảng 14.42 - Các giá trị delivery_system_hint

Bit

Mô tả

0b0001

Đây mà một mạng cáp và có thể là DVB-C và/ hoặc DVB-C2

0b0010

Đây là một mạng vệ tinh và có thể là DVB-S và/ hoặc DVB-S2

0b0100

Đây là một mạng mặt đất và có thể là DVB-T và/ hoặc DVB-T2

0b1000

Dự phòng.

Các CICAM có thể hỗ trợ nhiều hệ thống phân phối mà sẽ dẫn đến nhiều bit của trường này được thiết lập. Nếu máy chủ không hỗ trợ bất kỳ báo cáo hệ thống phân phối nào thì máy chủ có thể bỏ qua hồ sơ.

refresh_request_date: trường 16-bit này chỉ ra ngày của chu kỳ làm mới theo lịch tiếp theo được CICAM yêu cầu. Ngày được quy định theo MJD trong EN 300 468 [10], Phụ lục C. Giá trị 0x0000 chỉ ra rằng không yêu cầu làm mới theo lịch.

refresh_request_time: trường 8-bit này chỉ ra thời gian của chu kỳ làm mới theo lịch tiếp theo được CICAM yêu cầu. Thời gian được quy định theo UTC là một giá trị số nguyên với mỗi bước thời gian là 6 phút tính từ nửa đêm và có giá trị trong phạm vi từ 0 đến 239. Trường này chỉ được phân tích khi refresh_request_date khác không. Khi refresh_request_flag là số không thì trường này cũng phải là số không.

Ví dụ:

0

44

239

00:00 - na đêm

04:24 - 4 giờ 24 phút sáng

23:54 - nửa đêm kém 6 phút

14.7.5.4. operator_nit_req APDU

Máy chủ gửi APDU này cho CICAM để truy vấn NIT hiện tại. CICAM trả lời bằng một APDU operator_nit trả về CICAM NIT cho máy chủ.

Bảng 14.43 - Cú pháp operator_nit_req APDU

Cú pháp

Số bit

Kiểu

operator_nit_req() {
operator_nit_req_tag
length_field()
}


24


uimsbf

Trong đó các trường được quy định như sau:

operator_nit_req_tag: Xem bảng L.1 tại Phụ lục L.

14.7.5.5. operator_nit APDU

CICAM gửi APDU này đến máy chủ để trả lời một operator_nit_req () APDU. ADPU này, nếu thành công, chứa phần CICAM NIT mới nhất

Bảng 14.44 - Cú pháp operator_nit APDU

Cú pháp

Số bit

Kiểu

operator_nit 0 {
operator_nit_tag
length_field()
nit_loop_length
for (i=0; i<N; i++K){
nit_section_byte
}
}


24

16

8


uimsbf

uimsbf

uimsbf

Trong đó các trường được quy định như sau:

operator_nit_tag: Xem bảng L.1 tại Phụ lục L.

nit_loop_length: trường 16-bit này xác định độ dài tính theo byte của trường phần NIT tiếp theo chứa các phần CICAM NIT. Trường này có thể là không (0) nếu không có NIT.

nit_section_byte: vòng của một hoặc nhiều phần NIT mô tả đầy đủ mạng này. Một NIT chỉ được cung cấp khi thông tin mạng truyền hình và/hoặc Bouquet bị bỏ qua và được CICAM chuẩn bị. Các phần NIT này phải giữ nguyên các quy tắc tín hiệu truyền hình và phải có kích thước tối đa là 4096 byte, phải xuất hiện theo thứ tự số phần tăng dần và phải cha một giá trị CRC-32. Vòng NIT đầu tiên có thể được chia thành nhiều phn và phải tuân thủ các quy tắc chia của DVB. Vòng NIT thứ hai có thể được chia thành nhiều phần, các phần được đánh số liên tục và các nhãn

delivery_system_descriptor thích hợp và nhãn quy định dữ liệu riêng phải được xuất hiện trong mỗi phần.

Khi NIT này được trả về cho máy chủ thì phiên bản NIT này phải phù hợp với số phiên bản trong operator_status () APDU được thông báo cuối cùng. Phiên bản NIT này chỉ được khác nhau khi NIT này đã được cập nhật và CICAM chưa gỡ operator_status () APDU chứa thông tin nit_version mới nhất.

CICAM NIT phải chứa tất cả các thông tin mà máy chủ yêu cầu phải xây dựng và duy trì danh sách kênh logic của hồ sơ nhà điều hành. Không yêu cầu máy chủ truy vn thông tin dịch vụ truyền hình (SI) để xây dựng hoặc duy trì danh sách kênh hồ sơ này.

Vòng NIT đầu tiên này có thể tùy chọn chứa một tên mạng trong một network_name_descriptor ngoài các nhãn mô tả riêng CI Plus để cung cấp một dấu hiệu của hoạt động mạng truyền hình và ấn định các nhãn văn bản nội dung. Vòng đầu tiên này cũng có thể tùy chọn bao gồm thông tin tín hiệu truyền hình khác như DVB-SSU tuân theo tiêu chuẩn DVB.

Vòng NIT thứ hai phải chứa (các) nhãn system_delivery_descriptor xác định chính xác vị trí mạng của bộ ghép kênh ngoài một hoặc nhiều nhãn ciplus_service_descriptor mô tả nhãn văn bản và loại dịch vụ của mỗi dịch vụ được chứa trong danh sách kênh logic theo hồ sơ này. Các dịch vụ được ấn định một số kênh logic và có thể bị n.

Máy chủ phải luôn luôn giữ phạm vi nhãn mô tả riêng. Không yêu cầu máy chủ phân tích bất kỳ nhãn mô tả riêng khác gặp phải trong bất kỳ vòng NIT và phải bỏ qua bất kỳ nhãn mô tả không xác định.

Tham khảo Phụ lục N để có thông tin đầy đủ về hồ sơ.

14.7.5.6. operator_info_req APDU

Máy chủ gửi APDU này cho CICAM để truy vấn thông tin nhà điều hành. CICAM trả lời bằng một operator_info () APDU tr về thông tin nhà điều hành gần như tĩnh cho máy chủ.

Bảng 14.44 Cú pháp operator_info_req APDU

Cú pháp

S bit

Kiểu

operator_info_req() {
operator_info_req_tag
length_field()
}


24


uimsbf

Trong đó các trường được quy định như sau:

operator_info_req_tag: Xem bảng L.1 tại Phụ lục L.

14.7.5.7. operator_info APDU

CICAM gửi APDU này đến máy chủ để trả lời một operator_info_req () APDU. APDU này chứa thông tin quan trọng đối với máy chủ để phân tích và trình bày chính xác của cấu hình của SI này trong các bộ ghép kênh của mạng. Điều quan trọng là bất kỳ thông tin được cung cấp trong APDU này phù hợp chính xác hoạt động mạng thực tế nếu không thì hành vi của máy chủ thể bị ảnh hưởng xấu. Thông tin trong APDU này được xem là gần như tĩnh.

Bảng 14.45 - Cú pháp operator_info APDU

Trong đó các trường được quy định như sau:

operator_info_tag: Xem bảng L.1 tại Phụ lục L.

info_valid: đây là trường 1 bit, khi thiết lập là "1", chỉ ra rằng có các thông tin nhà khai thác. Bit này chỉ được thiết lập về "1" khi các thông tin nhà khai thác được phản ánh chính xác thông qua các nội dung của các mạng lưới phát sóng.

info_version: trường 3-bit này là một nhãn định danh duy nhất xác định phiên bản của thông tin hồ sơ được chứa trong APDU này. Phiên bản thông tin hồ sơ sẽ được tăng thêm 1, quay về 0, khi thông tin hồ sơ này thay đổi và yêu cầu máy chủ đánh giá lại nơi chứa hồ sơ. Phiên bản thông tin hồ sơ này chỉ được tăng lên khi có những thay đổi hồ sơ lớn bao gồm sự thay đổi tên hồ sơ, thay đổi loại hồ sơ v.v...

cicam_original_network_id: Trường 16-bit, xác định rõ định danh của original_network_id của các nhà điều hành dịch vụ theo sự phân bổ được tìm thy trong ETSI TS 101 162 [32]. Trường này có thể khác với original_network_id được thông báo trong mạng do sự phát triển lịch s của mạng.

cicam_identifier: trường 32-bit này xác định một trường hợp phần cứng cụ thể của CICAM. Các cicam_identifier phải là duy nhất để sử dụng kết hợp với CICAM_original_network_id để liên kết một CICAM với một hồ sơ nhà khai thác. Ví dụ, giá trị có thể được xây dựng bằng những việc sau đây:

• băm của CICAM_ID

• băm của số sê ri của thiết bị CICAM

• băm của trường số sê ri của xác thực thiết bị CICAM

• giá trị được xác định bởi nhà sản xuất CICAM

Các cơ hội của hai CICAM với cùng định danh sẽ phải ít hơn 1 trong 109. Máy chủ có thể sử dụng giá trị trường này kết hợp với các thông tin khác về CICAM để kết hợp một danh sách các kênh cấu hình tới một CICAM nhất định.

character_code_table: trường 8-bit này xác định việc mã hóa bộ ký tự mặc định đã được sử dụng trên mạng, trong đó nhà điều hành mạng đã thay đổi so với định dạng mã hóa ký tự DVB được quy định trong ETSI EN 300 468 [10], Phụ lục A. Mặc định là 0x00 trình bày bảng mã ký tự DVB 00 - bảng chữ cái Latin được quy định nghĩa trong tiêu chuẩn ISO/IEC 6937. Trong đó, giá trị character_code_table khác không đã được trường này xác định thì tất cả các trường văn bản của mạng, bao gồm các trường văn bản trong các nhãn mô tả riêng CI Plus của NIT, không bắt đầu với dữ liệu không hiển thị, không khoảng trống phải lấy mã ký tự được trường này và/hoặc các trường liên quan của nó quy định.

encoding_type_id: trường 8-bit này làm rõ trường character_code_table khi được thiết lập là 0x1f và chỉ ra cơ chế mã hóa của chuỗi ký tự theo phân bổ được quy định trong ETSI TR 101 162.

second_byte_value: trường 8-bit này làm rõ trường character_code_table khi được thiết lập là 0x10 và giá trị byte đầu tiên của 16-bit này được sử dụng để xác định bng mã ký tự theo quy định tại ETSI EN 300 468 [10], Phụ lục A, Bảng A.4.

third_byte_value: trường 8-bit này làm rõ trường character_code_table khi được thiết lập là 0x10 và giá trị byte thứ hai của 16-bit này được sử dụng để xác định bảng mã ký tự theo quy định tại ETSI EN 300 468 [10], Phụ lục A, Bảng A.4.

sdt_running_status_trusted: trường 1-bit này là một gợi ý cho máy chủ để xác định nếu trường running_status của SDT là chính xác, là đáng tin cậy và có thể được máy chủ phân tích. Khi trường này được thiết lập là "1" thì trạng thái đang chạy của SDT là đáng tin cậy và thiết bị thu máy chủ có thể chỉ ra các dịch vụ không trong trạng thái hoạt động đang chạy. Khi trường được thiết lập là "0", thì trạng thái đang chạy SDT phải được phân tích để luôn trong trạng thái đang chạy. Hoạt động máy chủ mặc định là "0".

eit_running_status_trusted: trường 1-bit này là một gợi ý cho máy chủ để xác định nếu trưng running_status của EIT là chính xác, là đáng tin cậy và có thể được máy chủ phân tích. Khi trường này được thiết lập là "1" thì trạng thái đang chạy của EIT là đáng tin cậy và chỉ ra một cách chính xác xem các dịch vụ có đang trong trạng thái hoạt động đang chạy. Khi trường được thiết lập là "0" thì máy chủ phải cho rằng trạng thái đang chạy của EIT luôn trong trạng thái hoạt động đang chạy. Hoạt động máy chủ mặc định là "0".

eit present_following_usage: trường 2-bit này mô tả trạng thái hoạt động của thông tin sự kiện EIT hiện tại/ tiếp theo trong mạng theo các giá trị trong Bảng 14.47. Hoạt động máy chủ mặc định thu được từ bộ ghép kênh nội bộ (1).

Bảng 14.47 - Các giá trị hoạt động hiện tại/tiếp theo của EIT

Giá trị

Mô tả

0

Không có bảng EIT.

1

Có bảng EIT trên mạng. Bảng EIT không được vận chuyển chéo đầy đủ và chỉ được phân phi trên bộ ghép kênh chứa dịch vụ. Máy chủ bắt buộc phải dò tìm xung quanh mạng để thu thập thông tin EIT đầy đủ. Các mạng vận chuyển chéo một phần phải gửi thiết lập này.

2

Có bảng EIT trên mạng và phải được vận chuyển chéo đy đủ. Máy chủ có thể ở lại trên cùng bộ ghép kênh để thu thập thông tin EIT đầy đủ.

3

Dự phòng.

eit_schedule_usage: trường 3-bit này mô tả trạng thái hoạt động của thông tin sự kiện theo lịch của EIT trong mạng theo các giá trị trong Bảng 14.48. Hoạt động máy chủ mặc định thu được từ bộ ghép kênh nội bộ (1) hoặc hoạt động kênh quảng cáo (3) khi một liên kết dịch vụ EPG là sẵn có.

Bảng 14.48 - Các giá trị hoạt động theo lịch của EIT

Giá trị

Mô tả

0

Không có bảng EIT.

1

Có bảng EIT trên mạng. Bảng EIT không được vận chuyển chéo đầy đủ và chỉ được phân phối trên bộ ghép kênh chứa dịch vụ. Máy chủ bắt buộc phải dò tìm xung quanh mạng để thu thập thông tin EIT đầy đủ. Các mạng vận chuyển chéo một phần phải gửi thiết lập này.

2

Có bảng EIT trên mạng và phải được vận chuyển chéo đầy đủ. Máy chủ có thể ở lại trên cùng bộ ghép kênh để thu thập thông tin EIT đầy đủ.

3

Có bảng EIT trên mạng và có sẵn từ một kênh Barker. Máy chủ buộc phải chuyển sang kênh Barker để thu thập thông tin EIT đầy đủ. Vị trí kênh Barker được thông báo trong bộ mô tả kết nối với Iinkage_type0x02 (EPGService) trong vòng đầu tiên của NIT.

4

Thông tin ElectronicProgrammeGuideinformation được phân phối sử dụng một ứng dụng.

5-7

Dự phòng.

extended_event_usage: trường 1-bit này xác định cách thông tin sự kiện mở rộng được trình bày và xác định liệu các trường văn bản short_event_descriptor (0x4d) và extended_event_descriptor (0x4e) có được sử dụng loại trừ lẫn nhau. Các giá trị này được quy định tại Bảng 14.49.

Bảng 14.49 - Các giá trị ngữ nghĩa sự kiện mrộng của EIT

Giá trị

Mô tả

0

Phần văn bản của extended_event_descriptor khác với short_event_descriptor và phi được ghép li cùng nhau để cung cấp thông tin s kin mở rộng.

1

Phần văn bản của extended_event_descriptor chứa phần văn bản của short_event_descriptor và các bộ mô tả này được sử dụng loại trừ lẫn nhau. short_event_descriptor được dùng riêng để cung cấp một mô tả ngắn, extended_event_descriptor được dùng riêng để cung cp một mô tả văn bản đầy đủ hơn.

sdt_other_trusted: trường 1-bit này xác định trạng thái tin cậy của các bảng SDT other trong mạng. Trường này phải được thiết lập là "1" khi SDT này hoàn toàn được truyền qua mạng này và có thể được máy chủ tin cậy vì thông tin trạng thái eit_event_trigger chính xác. Giá trị mặc định là "0" và thông tin trong SDTActual chỉ là đáng tin cậy.

eit_event_trigger: trường 1-bit này xác định nếu việc chuyển đổi sự kiện EIT hiện ti/tiếp theo trên mạng là đủ chính xác để được sử dụng cho việc ghi lại dựa trên sự kiện. Khi trường được thiết lập là "1" thì việc chuyển đổi sự kiện EITp/f (khi EIT tiếp theo trở thành EIT hiện tại) được chuyển đổi chính xác và có thể được sử dụng như tín hiệu kích hoạt để bắt đầu và dừng ghi lại của một sự kiện. Khi trường này là "0" thì việc chuyển đổi EIT p/f là không chính xác và máy chủ có thể sử dụng một cơ chế khác để đảm bảo rằng toàn bộ sự kiện được ghi lại tức là bổ sung thời gian 5 phút cho đoạn quảng cáo phim và đoạn dẫn đầu phim trước và sau thời gian sự kiện này thông báo.

Tín hiệu kích hoạt EIT p/f yêu cầu nhà điều hành dịch vụ sp xếp chính xác nội dung truyền hình với việc cung cấp sự kiện và chỉ cho phép các sự kiện được chuyển đổi khi thay đổi nội dung chương trình. Điều này yêu cầu nhà điều hành dịch vụ giữ sự kiện hiện tại khi một chương trình đang chạy chậm và chuyển đổi sang sự kiện tiếp theo khi một chương trình đang chạy nhanh.

ISO_639_language_code: trường 24-bit này xác định mã ngôn ngữ mặc định của các trường văn bản và các thành phần dòng thành phần chưa được dán nhãn. Mã ngôn ngữ mặc định được máy chủ sử dụng để thực hiện lựa chọn thành phần và văn bản trong trường hợp không có bất kỳ thông báo rõ ràng từ nhà điều hành dịch vụ. Các mã ngôn ngữ mà không xác định (bao gồm cả "und" hoặc "qaa") phải được giả định là mã ngôn ngữ mặc định được trường này quy định.

profile_name_length: trường 8-bit này xác định độ dài theo byte của trường văn bản tiếp theo mô tả tên hồ sơ. Đối với profile_type = 1 trường này phải luôn khác không và chứa một tên hồ sơ hợp lệ. Trường này có thể bằng không (0) nếu không có tên hồ sơ.

profile_name_byte: Đây là một trường 8-bit, một chuỗi các trường "char" quy định tên hồ sơ này. Thông tin văn bản được mã hóa bằng cách sử dụng các bộ ký tự và phương pháp được xác định trong ETSI EN 300 468 [10], Phụ lục A. Tên hồ sơ phải được sử dụng để dán nhãn cho một hồ sơ và phải được sử dụng ưu tiên hơn bất kỳ tên trên mạng được tìm thấy trong bất kỳ thông tin truyền hình hoặc CICAM NIT.

14.7.5.8. operator_search_start APDU

Máy chủ gửi APDU này cho CICAM để bắt đầu một trình tự tìm kiếm hồ sơ. Khi gửi APDU thì máy chủ bỏ quyền kiểm soát và chuyển quyền kiểm soát đó (MMI và dò kênh) cho CICAM. Trong trường hợp tìm kiếm này thì CICAM phải kiểm soát giao diện người sử dụng thông qua MMI ứng dụng hoặc cấp cao và có thể kiểm soát bộ dò kênh của máy chủ kênh để di chuyển trong mạng để có được thông tin hồ sơ. Khi CICAM hoàn thành việc tìm kiếm này thì nó phải trả lời cho máy chủ bằng một profile_search_status () APDU.

Bảng 14.50 - Cú pháp operator_search_start APDU

Cú pháp

Số bit

Kiểu

operator_search_start() {
operator_search_start_tag
length_field()
unattended_flag
service_type_loop_length
for (i=0; i<N; i++) {
service_type
}
delivery_capability_loop_length
for (i=0; i<N; i++){
delivery_capability_byte
}
application_capability_loop_length
for (i=0; i<N; i++) {
application_capability_byte;
}
}


24

1
7

8

8

8

8

8


uimsbf

bslbf
uimsbf

uimsbf

uimsbf

uimsbf

uimsbf

uimsbf

operator_search_start_tag: Xem bảng L.1 tại Phụ lục L.

unattended_flag: trường 1-bit này xác định xem máy chủ có đang hoạt động trong chế độ không tham gia (tức là không có mặt người sử dụng). Giá trị "1" chỉ ra rằng không có mặt người sử dụng và máy chủ là không thể sử dụng bất kỳ các yêu cầu tương tác. Khi máy chủ là không tham gia thì CICAM phải tránh sử dụng MMI cấp cao hoặc ứng dụng vì chúng có thể không được sử dụng. Giá trị "0” chỉ ra rằng người sử dụng có mặt và màn hình tương tác có thể được CICAM sử dụng.

service_type_loop_length: trường 7-bit này xác định số byte tiếp theo ngay sau trường này xác định danh sách service_type của máy chủ có thể sn có.

service_type: trường 8-bit này quy định loại dịch vụ mà máy chủ có thể sẵn có. Các giá trị loại dịch vụ được xác định bởi trường service_type trong service_descriptor được mô tả trong EN 300 468 [10].

Ví dụ:

 0x0102

Các dịch vụ truyền hình MPEG-2 (0x01) và phát thanh Layer-ll (0x02), MPEG-1 được hỗ trợ.

 

0x01020c

Các dịch vụ truyền hình MPEG-2 (0x01), phát thanh Layer-ll (0x02), MPEG-1 và dữ liệu được trường application_capability_byte (0x0c) xác định được hỗ trợ.

 

0x0102030a16

Các dịch vụ truyền hình MPEG-2 (0x01), phát thanh Layer-ll (0x02), MPEG-1, Teletext (0x03), phát thành mã hóa tiên tiến (0x0a) và video SD mã hóa tiên tiến (0x16) được hỗ trợ

 

0x0102030a101619

Các dịch vụ truyền hình MPEG-2 (0x01), phát thanh Layer-ll (0x02), MPEG-1, Teletext (0x03), phát thành mã hóa tiên tiến (0x0a), MHP (0x10), video SD (0x16) và HD (0x19) mã hóa tiên tiến nâng cao được hỗ trợ.

delivery_capability_loop_length: trường 8-bit này xác định độ dài theo byte của vòng delivery_capability.

delivery_capability_byte: trường 8-bit này mô tả (các) hệ thống cung cấp được máy chủ hỗ trợ. Mỗi hệ thống cung cấp được máy chủ hỗ trợ được nhãn mô tả hệ thống cung cấp.

descriptor_tag EN 300 468 [10] mô tả, bất kỳ nhãn mô tả mở rộng được bắt đầu bằng thẻ mô tả mở rộng (0x7F). Máy chủ có thể lựa chọn để thông báo tất cả các nhãn mô tả hệ thống cung cấp được hỗ trợ hoặc các nhã mô tả hệ thống cung cấp có thể áp dụng đối với chế độ hoạt động hiện tại của máy chủ.

Ví dụ:

 0x43

DVB-S. Một máy chủ chỉ có một bộ dò kênh truyền hình vệ tinh.

 

0x4379

DVB-S và DVB-S2. Một máy chủ có một bộ dò kênh truyền hình vệ tinh hỗ trợ S và S2.

 

0x5a7f0444

DVB-T, DVB-T2 và DVB-C. Một máy chủ có bộ dò kênh lai truyền hình mặt đất và cáp đa chức năng.

application_capability_loop_length: trường 8-bit này xác định độ dài theo byte của vòng application_capability.

application_capability_byte: trường 8-bit này mô tả nhiều hay không ứng dụng nào được máy chủ hỗ trợ. Mỗi ứng dụng được máy chủ hỗ trợ được mô tả bằng một giá trị data_broadcast_id 16-bit ETSI TR 101 162, nhiều môi trường ứng dụng được thông báo bằng cách bao gồm nhiều giá trị 16-bit tương ứng với từng môi trường ứng dụng được hỗ trợ. Máy chủ ch phải thông báo những loại ứng dụng sẵn có.

Các phiên bản của các hồ sơ ứng dụng chưa được xác định và không có gì đảm bảo rằng máy chủ có thể hỗ trợ phiên bản của bất kỳ môi trường ứng dụng nào.

Ví dụ:

0x00f0

Máy chủ hỗ trợ truyền hình MHP

 

0x0106

Máy chủ hỗ trợ truyền hình hồ sơ MHEG-5

 

0x01230107

Hỗ trợ máy chủ truyền hình HbbTV và Open TV

14.7.5.9. operator_search_cancel APDU

Máy chủ sẽ gửi APDU này đến CICAM để hủy một chuỗi tìm kiếm hồ sơ. Về việc ban hành APDU sau đó máy chủ yêu cầu CICAM chấm dứt việc tìm kiếm hồ sơ hiện tại và đáp ứng ngay với một operator_search_status () APDU. Các CICAM phải cố ngăn chặn việc tìm kiếm hồ sơ hiện hành càng nhanh càng tốt, ví dụ như không cần chờ đợi bất kỳ operator_tune_status nào ().

Bảng 14.51: Cú pháp operator_search_cancel APDU

Cú pháp

Số bit

Kiểu

operator_search_cancel() {
operator_search_cancel_tag
length_field() = 0
}


24


uimsbf

Trong đó các trường được quy định như sau:

operator_search_cancel_tag: Xem bng L.1 trong Phụ lục L.

14.7.5.10. operator_search_status APDU

APDU này được CICAM gửi để thông báo cho máy chủ rằng việc tìm kiếm hồ sơ đã được hoàn thành. Nội dung APDU giống như một operator_status () APDU ngoại trừ thẻ của APDU này.

Vào điểm cuối của việc tìm kiếm nhà khai thác thì CICAM phải thiết lập các thiết lập cờ trong operator_status_body () để phản ánh chính xác tình trạng hiện tại, ví dụ cờ refresh_request_flag sẽ phải được loại bỏ hoặc khởi tạo với yêu cầu tìm kiếm tiếp theo. Máy chủ sẽ xử lý operator_search_status () APDU như là một chỉ báo cho thấy việc tìm kiếm đã chấm dứt và sẽ xử lý bổ sung tất cả các lá cờ của operator_status_body () để xác định tình trạng hiện tại của hồ sơ cá nhân điều hành. Các CICAM không ban hành một APDU operator_status () bổ sung cho một operator_search_status () APDU vào điểm cuối của tìm kiếm.

Bảng 14.52 - Cú pháp operator_profile APDU

Cú pháp

Số bit

Kiểu

operator_search_status () {
operator_search_status_tag
length_field()
operator_status_body()
}


24


uimsbf

Trong đó các trường được quy định như sau:

operator_search_status_tag: Xem bảng L.1 tại Phụ lục L.

operator_status_body (): Xem Bảng 14.38 trong phần 14.7.5.3.

14.7.5.11. operator_tune APDU

CICAM gửi APDU này đến máy chủ để yêu cầu một hoạt động dò kênh trong trường hợp operator_search 0 APDU dưới sự kiểm soát của máy chủ khi một hoạt động tìm kiếm hồ sơ được yêu cầu. APDU này không được sử dụng để dò kênh ngoài trường hợp này. Máy chủ trả lời bằng một operator_tune_status () APDU khi hoạt động dò kênh này đã được hoàn thành. APDU này cho phép CICAM thực hiện hoạt động dò kênh trực tiếp.

Yêu cầu máy chủ dò kênh đến v trí được trường delivery_system_descriptor quy định và để dòng truyền tải của v trí này truyền qua CICAM. Nhiều vị trí có thể được APDU này xác định và máy chủ phải cố gắng dò kênh từng vị trí theo thứ tự mà chúng được thể hiện trong APDU này cho đến khi máy chủ xác định một tín hiệu truyền dữ liệu hợp lệ khi việc tìm kiếm kết thúc mà không có bất kỳ xử lý nào đối với các vị trí này và một operator_tune_status () APDU được trả về cho CICAM xác định đã tìm thấy bộ ghép kênh này.

Máy chủ phải tính các nhãn mô tả được xử lý trong vòng nhãn mô tả của APDU này và yêu cầu máy chủ phải trả về số của nhãn mô tả của nhãn mô tả chưa được xử lý tiếp theo cho CICAM trong operator_tune_status () APDU khi hoàn thành việc dò kênh. Việc tính nhãn mô tả bắt đầu từ 0 tương ứng với nhãn mô tả đầu tiên của vòng này.

Việc xử lý của máy chủ đối với yêu cầu dò kênh được mô tả sau đây:

Máy chủ phải sử dụng bất kỳ sự hỗ trợ phần cứng của bộ dò kênh để tăng tốc độ tìm kiếm và có thể bỏ qua các vị trí dò kênh không khởi tạo một hoạt động dò kênh rõ ràng nếu vị trí dò kênh này được cho là đã được phần cứng này tìm kiếm trước đó. Việc tối ưu hóa máy chủ này dựa vào việc CICAM nhóm một cách chính xác các yêu cầu dò kênh tương tự nhau sao cho máy chủ có thể xác định và loại bỏ các vị trí này.

Bảng 14.53 - Cú pháp operator_tune APDU

Cú pháp

S bit

Kiểu

operator_tune () {
operator_tune_tag
length_field()
reserved
descriptor_loop_length
for (i=0; i<N; i++) {
descriptor()
}
}


24

4
12

8


uimsbf

bslbf
uimsbf

uimsbf

Trong đó các trường được quy định như sau:

operator_tune_tag: Xem bảng L.1 tại Phụ lục L.

Iength_field (): APDU này phải bị giới hạn tối đa là 2048 byte để cho phép 157 system_delivery_descriptor với độ dài 13 byte.

descriptor_loop_length: trường 12-bit này xác định độ dài theo byte của vòng descriptor() tiếp theo trường này.

descriptor(): vòng các nhãn mô tả hệ thống cung cấp mô tả vị trí yêu cầu CICAM dò kênh. Vòng nhãn mô tả này phải bao gồm một hoặc nhiều nhãn mô tả hệ thống cung cấp đều từ cùng một hệ thống cung cấp. CICAM phải tạo một bộ thông số dò kênh đầy đủ và tối ưu trong nhãn mô tả cung cấp này, tức là các tần số phải được nhóm lại v.v... Máy chủ phải cố gắng dò kênh từng vị trí được quy định và xác định tín hiệu khả thi có dấu hiệu truyền dữ liệu phù hợp, ngay sau khi máy chủ xác định một vị trí tín hiệu truyền, hoặc đến cuối danh sách nhãn mô tả, thì hoạt động dò kênh này được dừng lại và trạng thái này được thông báo cho CICAM bằng một operator_tune_status () APDU.

14.7.5.12. operator_tune_status APDU

Máy chủ gửi APDU này cho CICAM để trả lời một operator_tune () hoặc APDU sau khi máy chủ đã dò kênh đến vị trí được yêu cầu.

Bảng 14.54 - Cú pháp operator_tune_status APDU

Cú pháp

Số bit

Kiểu

operator_tune_status () {
operator_tune_status_tag
length_field()
descriptor_number
signal_strength
signal_quality
status
descriptor_loop_length
for (i=0; i<N; i++){
descriptor()
}
}


24

8
8
8
4
12

8


uimsbf

uimsbf
uimsbf
uimsbf
uimsbf
uimsbf

uimsbf

Trong đó các trường được quy định như sau:

operator_tune_status_tag: Xem bảng L.1 tại Phụ lục L.

descriptor_number: trường 8-bit này xác định số của nhãn mô tả chưa được xử lý tiếp theo trong operator_tune () APDU mà chưa được máy chủ xử lý, giá trị 0xFF chỉ ra rằng máy chủ đã đến cuối của bảng này. Các nhãn mô tả được tính từ 0, việc xử lý descriptor_number được mô tả trong phần văn bản giới thiệu dành cho operator_tune () APDU.

Bảng 14.55 - Các giá trị trạng thái

Giá tr

Mô tả

0

Hoạt động dò kênh thành công và máy chủ đã chuyển thành công tới vị trí được yêu cầu; bộ dò kênh bị khóa và một tín hiệu số có sẵn. Dòng tín hiệu vận chuyển phải đi qua CICAM.

Trường descriptor_number phải là số chưa được xử lý tiếp theo.

Trường signal_strength phải khác không.

Trường signal_quality phải khác không.

Trường descriptors() phải cha các delivery_system_descriptor mô tả vị trí dò kênh đạt yêu cầu hiện thời. Bộ mô tả này có thể sai khác một chút so với bộ mô tả phân phối CICAM gốc nếu thông tin này đã được sửa bởi thông tin bộ dò kênh của máy chủ.

1

Bộ mô tả hệ thống phân phối không được hỗ trợ bởi máy chủ.

Trường descriptor_number phải là số hiệu bộ mô tả chưa được xử lý tiếp theo. Trường signal_strength phải bằng không.

Trường signal_quality phải bằng không.

Trường descriptor_loop phải chứa các bộ mô tả không được hỗ trợ.

2

Tham số bộ mô tả hệ thống phân phối không hợp lệ.

Trường descriptor_number phải là số hiệu bộ mô tả chưa được xử lý tiếp theo.

Trường signal_strength phải bằng không.

Trường signal_quality phải bằng không.

Trường descriptor_loop phải chứa các bộ mô tả không hợp lệ.

3

Hoạt động dò kênh thành công và máy chủ đã chuyển thành công tới vị trí được yêu cầu và không có tín hiệu.

Trường descriptor_number phải bằng 0xff vì danh sách bộ mô tả đã được dò hết.

Trường signal_strength phải bằng không.

Trường signal_quality phải bằng không.

Trường descriptor_loop_length phải bằng không.

4-15

Dự phòng.

Trường hợp máy chủ thông báo một delivery_system_descriptor không xác định hoặc không hợp lệ thì máy chủ phải dừng tìm kiếm và trả về system_delivery_descriptor bị lỗi đến CICAM. CICAM sau đó có thể tạo lại danh sách dò kênh với một tập các vị trí dò kênh mới không chứa các mô tả có cùng một loại nếu tìm kiểm này được tiếp tục.

signal_strength: trường 8-bit này xác định cường độ tín hiệu theo giá trị phần trăm từ 0 đến 100, trong đó 0 là không có tín hiệu và 100 là một tín hiệu cường độ mạnh nhất. Lưu ý rằng chỉ số cường độ tín hiệu không phải là thước đo chất lượng tín hiệu và phải truy vấn trường signal_quality để đánh giá chất lượng tín hiệu.

signal_quality: trưng 8-bit này xác định chất lượng của tín hiệu theo giá trị phần trăm từ 0 đến 100, trong đó 0 đại diện cho một tín hiệu có chất lượng không khả thi và 100 là một tín hiệu hoàn hảo.

status: 4-bit này là trạng thái của yêu cầu dò kênh. Các giá trị trạng thái được quy định trong Bảng 14.53.

descriptor_loop_length: trường 12-bit này xác định độ dài theo byte của vòng descriptor() tiếp theo trường này.

descriptor(): vòng các nhãn mô tả hệ thống cung cấp mô tả vị trí được dò kênh hiện tại của máy chủ được truyền qua CICAM hoặc các nhãn mô tả gây ra lỗi. Vòng nhãn mô tả chỉ được chứa một vị trí hệ thống cung cấp duy nhất, nó có thể được mô tả bng một hoặc nhiều nhãn mô tả.

14.7.5.13. operator_entitlement_ack APDU

Máy chủ gửi APDU này cho CICAM để xác nhận rằng bất kỳ thay đổi về quyền đã được máy chủ xử lý, điều này có thể dẫn đến một thay đổi trong danh sách kênh logic v.v. CICAM phải gửi operator_status () APDU để trả lời lệnh này bằng trường entitlement_change_flag bị xóa.

Bảng 14.56 - Cú pháp operator_entitlement_ack APDU

Cú pháp

S bit

Kiểu

operator_entitlement_ack() {
operator_entitlement_ack_tag
length_field()
}


24


uimsbf

Trong đó các trường được quy định như sau:

operator_entitlement_ack_tag: Xem bảng L.1 tại Phụ lục L.

14.7.5.14. operator_exit APDU

Máy chủ gửi APDU này cho CICAM để thông báo cho CICAM rằng máy chủ đã rời khỏi môi trường profile_type = 1 và đang hoạt động trong một danh sách kênh khác hoặc trường hợp khác. Bất kỳ dòng truyền tải truyền qua CICAM có thể không có nguồn gốc từ môi trường hồ sơ nhà điều hành này cho đến khi máy chủ trở lại môi trường nhà điều hành này được thông báo bằng một operator_status_req () APDU.

Bảng 14.57 - Cú pháp operator_exit APDU

Cú pháp

Số bit

Kiểu

operator_exit() {
operator_exit_tag
length_field()
}


24


uimsbf

Trong đó các trường được quy định như sau:

operator_exit_tag: Xem bảng L.1 tại Phụ lục L.

 

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

Bộ tạo số ngẫu nhiên được sử dụng để tạo ra các số ngẫu nhiên sau đây trong tiêu chuẩn này:

Bảng A1 - Các số ngẫu nhiên

Trường

Độ dài (bit)

Diễn giải

DHX

2048

Số mũ Diffie Hellman “x”

DHY

2048

Số mũ Diffie Hellman y

Kp

256

Tiền thân của mã khóa CCK của CICAM đến máy chủ

Ns_Host

64

Yêu cầu SAC của máy chủ đến CICAM

Ns_Module

64

Yêu cầu SAC của CICAM đến máy chủ

Auth_nonce

256

Nonce trong giao thức xác thực

Bộ tạo số ngẫu nhiên phải tuân theo một trong hai điều sau đây:

1) PRNG được mô tả trong SCTE 41 [5], điều 4.6.

Chú ý: Giá trị nhân duy nhất được tạo ra là pmg_seed trong tiêu chuẩn này. Trừ khi được ghi rõ ràng, các giá trị nhân này phải được xem là rất bí mật như được mô tả trong Bản quy định kỹ thuật cấp giấy phép CI Plus [33]. Việc triển khai SHA nên tuân theo danh sách xác nhận SHS, tham khảo Danh sách xác nhận SHS [11].

2) Thuật toán dựa vào AES theo ANSI X 9,31 [12] được minh họa trong hình A.1 và mô tả dưới đây:

Hình A.1 - Ví dụ PRNG dựa trên AES

Trong hình A.1, k là một giá trị không đổi 128-bit, DTi là một giá trị 128 bit được cập nhật vào mỗi lần lặp (ví dụ như véc-tơ ngày/thời gian hoặc bộ đếm đều đều) và s là một giá trị nhân. CICAM và máy chủ phải có một giá trị nhân duy nhất được tạo ra S.

Chú ý: Trừ khi được ghi rõ ràng, các giá trị k và S phải được xem là rất bí mật như được mô tả trong thỏa thuận cấp giấy phép.

Sự kết hợp của giá trị cố định k và giá trị nhân ban đầu S phải không thể đoán trước và duy nhất dành cho mỗi sản phẩm được cấp giấy phép. Bộ tạo nhân dành cho S phải tuân theo SP800-22b [36]. Nếu không có bộ tạo nhân dành cho S thì S phải được duy trì trong một thanh ghi không thay đổi, trong trường hợp này không yêu cầu một nguồn dữ liệu ngẫu nhiên. Ngoài ra DT phải đảm bảo là không lặp lại cho đến thời gian kế tiếp sản phẩm được cấp giấy phép này được khởi tạo lại.

Các giá trị 128 bit ngẫu nhiên Ri( i = 0,1...) được tạo ra như sau:

Ii = EAES-128{k}(DTi)

Eq.A.1

Ri = EAES-128{k}(IiÅSi)

Eq.A.2

Si=1 = EAES-128{k}(IiÅRi)

Eq.A.3

Đối với các số ngẫu nhiên không phải là một bội số chính xác của kích thước khối AES thì khối AES cuối cùng được cắt ngắn LSB theo độ dài được quy định tại Bảng A.1.

 

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ị

Lưu ý: Định dạng ID thiết bị không được định nghĩa trong tiêu chuẩn này và có thể được lấy từ Đặc tả về giấy phép CI Plus [33].

 

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ần này bị phản đối. Giao tiếp giữa các CICAM và các nhà khai thác dịch vụ không nằm trong phạm vi của tiêu chuẩn này.

 

Phụ lục D

(quy định)

Các khả năng SD và HD

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

Trong tiêu chuẩn này định nghĩa một thiết bị SD hoặc một thiết bị HD không được xác đnh. Một thiết bị HD là một thiết bị có thể xử lý và giải mã tín hiệu HD được truyền qua giao diện chung. Ví dụ, điều này có nghĩa là thiết bị HD tuân th logo HD TV của EICTA. Một số quốc gia hay lục địa có những định nghĩa khác nhau của các chương trình logo, các định nghĩa logo khác có thể áp dụng cho phù hợp với các khả năng xử lý tín hiệu 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.1.1. Bản quy định kỹ thuật

Tiêu chuẩn PCMCIA định nghĩa trong tập 2, điều 4.4.6 rằng máy chủ phải đợi 5 giây để thiết lập tín hiệu sẵn sàng. Nội dung sau được lấy từ bản quy định kỹ thuật được trình bày in nghiêng.

Thẻ mà yêu cầu nhiều hơn 20 ms để khởi tạo nội bộ trước khi việc truy nhập bị từ chối SẴN SÀNG cho đến khi nó đã sẵn sàng cho việc truy nhập ban đầu, khoảng thời gian không được nhiều hơn 5 giây sau thời điểm mà tín hiệu THIT LP LẠI bị từ chối (hoặc nếu không thực hiện thiết lập lại thì VCC là ổn định).

E.1.2. Yêu cầu

Máy chủ phải kiểm tra một cách rõ ràng tín hiệu SN SÀNG cho đến khi nó được mô-đun này thiết lập hoặc cho đến khi thời gian chờ 5 giây đã hết.

E.2. CA_PMT rõ ràng

E.2.1. Bản quy định kỹ thuật

Bản quy định kỹ thuật DVB-CI xác định trong "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 (R206-001:1998)" [24] rằng máy chủ phải gửi đối tượng ca_pmt ngay ckhi chương trình được lựa chọn là rõ ràng. Nội dung sau được ly từ bn quy định kỹ thuật được trình bày in nghiêng.

CA_PMT được máy ch gi ngay cả khi chương trình rõ ràng được người sử dụng lựa chọn (thường là một chương trình không có CA_descriptor trong PMT). Trong trường hợp này, máy ch phải gửi CA_PMT mà không có bất kỳ CA_descriptor (ví dụ: CA_PMT với program_info_length == 0 và ES_info_length == 0).

E.2.2. Yêu cầu

Máy chủ phải gửi CA_PMT ngay c khi chương trình lựa chọn là rõ ràng (FTA).

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

E.3.1. Bản quy đnh kỹ thuật

Hướng dẫn thực hiện và sử dụng giao diện chung cho các ứng dụng bộ giải mã DVB (R206-001 [24]; điều 9.5.6.2) đã được định nghĩa:

Chuyển từ xáo trộn sang giải xáo trộn và ngược lại

• Khi một chương trình chuyển từ xáo trộn sang rõ ràng, có một số khả năng:

1. Sự thay đổi này không được thông báo trong PMT, nhưng lại có trong trường TSC của phần mào đầu gói tin hoặc trong trường PES_SC của phần mào đầu PES. Trong trường hợp này, máy chủ không có lý do nào để gi một CA_PMT mới để loại bỏ chương trình này trong danh sách. Chương trình này vẫn được lựa chọn và máy chủ vn tiếp tục gửi CA_PMT khi version_number của PMT tăng lên.

2. Thay đổi này dẫn đến sự thay đổi của PMT. Trong trường hợp này, một CA_PMT được máy chủ gửi.

• Khi một chương trình chuyển từ rõ ràng sang xáo trộn, có một số khả năng:

1. Sự thay đổi này không được thông báo trong PMT, nhưng lại có trong trường TSC của phần mào đầu gói tin hoặc trong trường PES_SC của phần mào đầu PES. Trong trường hợp này, máy chủ không gửi một CA_PMT mới. ng dụng CA phải phát hiện ra sự chuyển đổi đó.

2. Thay đổi này dẫn đến sự thay đổi của PMT (ví dụ: các CA_descriptor bị loại bỏ). Trong trường hợp này, một CA_PMT được máy chủ gửi.

Chú ý: Trong cả hai trường hợp, ứng dụng CA nên tạo ra một tương tác với người sử dụng để thông báo cho người sử dụng.

E.3.2. Khuyến nghị

ng dụng CA không được tạo ra một tương tác với người sử dụng khi không cần thiết.

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

E.4.1. Bản quy định kỹ thuật

R206-001 [24] (điều 9.5.5.1) đã mô trằng:

Nếu máy chủ muốn cập nhật một CA_PMT của một trong những chương trình trong danh sách thì nó gửi một CA_PMT với ca_pmt_list_management == cập nhật. Điều này xảy ra khi máy chủ phát hiện ra version_number hoặc current_next_indicator của PMT đã thay đi. Sau đó ng dụng CA trong mô-đun kiểm tra xem sự thay đổi này có những hệ quả trong hoạt động CA hay không. Nó cũng xảy ra khi danh sách các dòng thành phần của một chương trình được lựa chọn thay đổi (ví dụ: người sử dụng đã lựa chọn một ngôn ngữ khác). Trong trường hợp này, máy chủ phải gửi lại toàn bộ danh sách các dòng thành phần của chương trình được cập nhật đó.

E.4.2. Khuyến nghị

Khi phiên bản PMT đã thay đổi, đối tượng CA_PMT_Update phải được sử dụng để tránh một màn hình màu đen.

E.5. MMI tức thời

E.5.1. Bản quy định kỹ thuật

R206-001 [24] (điều 9.5.6.1) đã định nghĩa:

Các ứng dụng CA hiện tại không hoạt động cho bất kỳ chương trình hiện tại được người sử dụng lựa chọn có thể tạo ra các phiên MMI dành cho tương tác với người sử dụng, ví dụ như để cảnh báo về một sự kiện PPV sắp xảy ra trên một chương trình khác đã được người sử dụng mua trước đó.

E.5.2. Giải pháp

Hiển thị tất cả các bản tin MMI được CICAM gửi. Không cho phép tự động MMI đóng, cho phép người sử dụng đóng MMI.

CICAM phải xử lý các tình huống khi máy chủ đang bận và không thể trả lời yêu cầu của CICAM về việc hiển thị một bản tin MMI tức thời. Trong trường hợp này, máy chủ trả về một đối tượng open_session_response với F3 session_status (nguồn bận) khi mô-đun cố gắng m phiên MMI. Mô-đun có thể th mlại một phiên MMI cho đến khi máy chủ có thể m phiên này nhưng phải xem xét xem một số bản tin có bị lỗi thời khi dch vụ hiện tại đã thay đổi (ví dụ như một bản tin MMI tức thời là "bạn không được phép xem chương trình này").

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

E.6.1. Bản quy định kỹ thuật

Bản quy đnh kỹ thuật DVB-CI trong EN 50221 [7] (điều 5.4.3) định nghĩa rằng một kết ni dòng truyền tải phải được thiết lập nếu mô-đun này tuân thủ DVB. Nội dung sau được lấy từ bản quy định kỹ thuật được trình bày in nghiêng.

Khi một mô-đun không được kết nối, giao diện dòng truyền tải phải bỏ qua mô-đun này và giao diện lênh của mô-đun này phải là không hoạt động. Khi có kết nối với mô-đun, máy chủ phải khởi tạo một trình tự khởi tạo cấp thấp với mô-đun này. Điều này sẽ thực hiện bất cứ thủ tục thiết lập kết nối cấp thấp được lớp vật lý cụ th sử dụng, và sau đó xác nhận rằng mô-đun này tuân thủ DVB. Nếu thành công hoàn toàn, máy chủ phải thiết lập kết nối dòng truyền ti bằng cách chèn mô đun này vào đường dẫn dòng truyền tải của máy chủ. Có thể chấp nhận rằng một số dữ liệu của dòng truyền tải bị mt trong quá trình này.

E.6.2. Giải pháp

Luôn luôn gửi dòng truyền tải đến CICAM khi nó đã được khởi tạo.

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

E.7.1. Bản quy định kỹ thuật

Bản quy định kỹ thuật DVB-CI trong EN 50221 [7] (điều 8.4.1.1) định nghĩa rng khi một truy vấn hồ sơ được máy chủ hoặc mô-đun gửi, một trả lời về hồ sơ phải được mô-đun hoặc máy chủ gửi. Nội dung sau được lấy từ bản quy định kỹ thuật được trình bày in nghiêng.

Khi một mô-đun được ghép vào hoặc máy chủ được bật nguồn điện thì một hoặc hai kết nối truyền ti có thể được tạo ra đến mô-đun, đáp ứng một ứng dụng và/hoặc một nhà cung cấp tài nguyên.

Điều đầu tiên một ứng dụng hoặc nhà cung cấp tài nguyên làm là yêu cầu một phiên đến tài nguyên Nhà quản lý tài nguyên, được tạo ra không thay đổi vì nhà quản lý tài nguyên không có hạn chế phiên. Sau đó Nhà qun lý tài nguyên gi một yêu cầu hồ sơ cho ng dụng hoặc nhà cung cấp tài nguyên này để được trả lời bằng một trả lời hồ sơ liệt kê các tài nguyên mà nó cung cấp (nếu có), ứng dụng hoặc nhà cung cấp tài nguyên bây giờ phải chờ đợi một đối tượng thay đi hồ sơ. Trong khi chờ đi đối tượng thay đổi hồ sơ này nó không được tạo ra các phiên đến các tài nguyên khác cũng như không được chp nhận các phiên từ các ứng dụng khác, mà trả về một trả lời là tài nguyên không tồn tại’ hoặc tài nguyên tồn tại nhưng không có sẵncho phù hợp.

E.7.2. Khuyến nghị

Trả lời đối với đối tượng yêu cầu hồ sơ.

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

E.8.1. Giới thiệu

Trong nhiều thiết lập, một khe PCMCIA dùng chung địa chỉ và các đường dữ liệu với các thiết bị khác như một khe PCMCIA thứ hai hoặc một chip bộ nhớ cực nhanh. Mỗi thiết bị sẽ có đường cho phép chip riêng, đường này điện áp thấp khi việc truy nhập hiện tại liên quan đến một thiết bị cụ thể này. Đối với một khe PCMCIA, đường cho phép chip này được kết nối với chân CICAM Chip Enable # 1 (CE1 #), Chip Enable # 2 (CE2 #) không sử dụng.

E.8.2. Khuyến nghị

CICAM phải kiểm tra chân CE1 # của nó và chắc chắn rằng nó là điện áp thấp trước khi xử lý bt kỳ dữ liệu từ bus dữ liệu. Khi chân Chip Enable # 1 (CE1 #) điện áp cao, CICAM không được gửi bất kỳ dữ liệu hoặc thay đổi trạng thái nội bộ của nó dựa trên các tín hiệu từ bus dữ liệu.

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

EN 50221 [7] điều 7 quy định:

Các đối tượng được mã hoá bằng mã hóa Tag-Length-Value chung theo mã hóa được sử dụng đ mã hóa cú pháp ASN.1.

Và tiếp theo trong phần này quy định:

Do đó bất kỳ giá trị độ dài trường có giá trị lên đến 65535 có thể được mã hóa bằng ba byte.

Các nguyên tắc mã hóa cơ bn ASN.1 (BER) cho phép mã hóa với các độ dài sử dụng nhiều hơn ba byte. Việc sử dụng định dạng dài này cho một giá trị độ dài có thể sử dụng tối đa 127 byte đối với một độ dài được mã hóa có độ dài 128 byte để đại diện cho một độ dài lớn hơn 10305 byte.

Đoạn thứ hai trong văn bản của EN 50.221 thực chất là một ví dụ về cách chúng ta có thể sử dụng ba byte để mã hóa một độ dài. Chúng ta đu có thể đưa ra một ví dụ sử dụng bốn byte để có thể mã hóa một độ dài lên đến 16 777 216 byte.

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

E.10.1. Bn quy định kỹ thuật

Tài nguyên kiểm soát máy chủ 00x200041 là bắt buộc đối với một máy chủ Cl Plus, nó cho phép CICAM dò kênh đến một dịch vụ để nâng cấp CAM theo quy định tại điều 14.3 và các ứng dụng loại Video on Demand.

E.10.2. Khuyến nghị

Việc kiểm soát máy chủ chỉ được sử dụng khi người sử dụng tương tác với CICAM cho phép CICAM dò kênh đến một dịch vụ khác (tức là nâng cp CAM và MMI).

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

E.11.1. Bản quy định kỹ thuật

Bản quy định kỹ thuật DVB-CI định nghĩa trong EN 50221 [7] (điều 8.4.3.5). Đối tượng này luôn được ứng dụng này gửi đến máy chủ sau khi nhận một đối tượng CA PMT với ca_pmt_cmd_id được thiết lập là ‘truy vấn’. Nó cũng có thể được gửi sau khi nhận một đối tượng CA PMT với ca_pmt_cmd_id được thiết lập là 'ok_mmi' để thông báo cho máy chủ kết quả của tương tác MMI ('descrambling_possible' nếu người sử dụng đã mua, ‘descrambling not possible’ (vì không có quyền) nếu người sử dụng chưa mua).

E.11.2. Khuyến nghị

CICAM phải luôn luôn gi một CA-PMT Reply khi đối tượng PMT được gửi với ca_pmt_cmd_id được thiết lập là 'truy vn'.

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

E.12.1. Bản quy định kỹ thuật

Tài nguyên CC trong Cl Plus cho phép tăng cường kiểm soát nội dung bằng cách sử dụng URI như được định nghĩa trong điều 5.7, các phần m rộng trong DVB TS 101 699 [8], điều 6.6, cung cấp tài nguyên CP để kiểm soát nội dung. Cả hai tài nguyên này được sử dụng để kiểm soát việc phân phối nội dung và không bao giờ được mở cùng một lúc.

E.12.2. Khuyến nghị

CICAM không được mở một phiên cho cả hai tài nguyên CC và tài nguyên CP cùng một lúc. Máy chủ phải trả lời 'phiên không mở, tài nguyên tồn tại nhưng không sẵn sàng (0xf1)'

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

E.13.1. Giao diện dữ liệu

EN 50221 [7] điều 5.4.2.5 quy định:

Tt cả giao diện phải hỗ trợ tốc độ dữ liệu trung bình ít nhất là 58 Mb/s trong khoảng giữa các byte đồng bộ của các gói tin truyền tải liên tiếp.

Tiêu chuẩn này làm tăng yêu cầu đối với tốc độ dữ liệu này. Các CICAM tuân th tiêu chun này phải hỗ trợ 96 Mb/s. Máy chủ tuân thủ tiêu chuẩn này có băng thông đủ lớn dành cho các giao diện mạng của chúng. Tham khảo điều 11.1.3 để biết thêm thông tin về các yêu cầu tốc độ dữ liệu Cl Plus.

E.13.2. Giao diện lệnh

EN 50221 [7] điều 5.4.2 quy định:

Giao diện lệnh phải truyền các lệnh theo quy định của phần Lớp Truyền tải phù hợp trong tiêu chuẩn này theo cả hai hướng. Tốc độ dữ liệu được hỗ trợ trong mỗi hướng phải ít nhất là 3,5 Mbit/giây.

Yêu cầu này ch được áp dụng cho tiêu chuẩn này.

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

E.14.1. Bản quy định kỹ thuật

Trong điều 8.7.1.5 của EN 50221 [7] return_value trong phần mô tả của mã hóa đối tượng Comms Reply được phân loại theo kiểu uimsbf”. Tuy nhiên, trong văn bản của bản quy định kỹ thuật này quy định là return_value chứa các giá trị âm để chỉ ra lỗi và đặc biệt là giá trị -1 dành cho các lỗi không xác định.

E.14.2. Khuyến nghị

Trường return_value 8 bit trong một comms_reply APDU nên được phân tích là một giá trị “hai thành phần" có dấu.

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

E.15.1. Bản quy định kỹ thuật

Điều 8.6.5.1 của EN 50221 [7] quy định rằng thông tin văn bản được mã hóa bng cách sử dụng các bộ ký tự và phương pháp được mô ttrong EN 300 468 [10] và văn bản đó được ứng dụng này gi có thể bao gồm các ký tự kiểm soát như được quy định trong [10] đ cung cấp chỉ dẫn về cách hiển thị sẽ được trình bày.

Máy chủ có thể trình bày bất kỳ đối tượng văn bản mà không có một byte lựa chọn bảng ký tự đứng trước như Bảng 00 - Bảng chữ cái Latinh như trong EN 300 468 [10] Phụ lục A1, hình A.1, mà có thể không phải là những gì CICAM muốn.

E.15.2. Khuyến ngh

CICAM luôn luôn bao gồm một byte lựa chọn bảng ký tự đứng trước để đm bảo rng máy chủ sử dụng bảng ký tự chính xác. Xem EN 300 468 [10] Phụ lục A

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

E.16.1. Bản quy định kỹ thuật

Điều 8.5.1.1 của EN 50221 [7] mô tả cách thức tài nguyên kiểm soát máy chủ cho phép CICAM hướng dẫn máy chủ dò kênh đến một vị trí khác. Vị trí mới này được tổ hợp của network_id, original_network_id, transport_stream_id và service_id xác định. Hành vi của thiết bị thu khi một số các giá trị là số không và bất kỳ phương pháp thiết lập giá trị thẻ không được mô tả.

E.16.2. Khuyến nghị

network_id không nên được sử dụng. Giá trị không (0) phải được xem xét đối với thẻ hoặc không được sử dụng. Nên chỉ có hai tổ hợp hợp lệ của thông số dò kênh và giá trị thẻ. Tổ hợp hợp lệ được trình bày trong Bảng E.1.

Bảng E.1 - Tổ hợp hợp lệ của các thông số đối tượng dò kênh kiểm soát máy chủ DVB

network_id

transport_

stream_id

original

network_id

service_id

Thực hiện

0

TSID

ONID

SID

Dò kênh kếnh một dịch vụ, dịch vụ này phải tồn tại

0

TSID

ONID

0

Dò kênh đến một bộ ghép kênh, máy chủ không lựa chọn dịch vụ, ca_pmt sẽ không được máy chủ gửi.

CHÚ THÍCH: Giả thiết rng thiết bthu có vị trí mong muốn đã được tham chiếu trong danh sách dịch vụ của nó để có thể lấy các thông số dò kênh thực. Danh sách dịch vụ của máy chủ có thể ch chứa các dịch vụ mà máy chủ có thể nhn biết, tức là chỉ các dịch vụ truyền hình và phát thanh

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

E.17.1. Bản quy định kỹ thuật

EN 50221 [7], điều 8.4.3.4 quy định:

CA PMT chứa tất cả các CA_descriptor của chương trình được lựa chọn. Nếu một số chương trình được lựa chọn, máy chủ gửi một số đối tượng CA PMT đến ứng dụng này. CA_PMT chỉ chứa các CA_descriptor. Tất cả các nhãn mô tả khác phải được máy chủ loại b khỏi PMT.

R206-001:1998 [24], điều 9.5.5 quy định:

Nếu sử dụng các kỹ thuật mã hóa đồng thời thì một mục nhập cho một chương trình trong PMT có thể chứa các CA_descriptor dành cho nhiều hơn một CA ID. Trong trường hợp này, đối tượng CA_PMT phải chứa tất cả các CA_descriptor được sử dụng, và thiết bị thu sẽ không cố gắng lựa chọn dựa trên (các) CA ID được một ng dụng CA cụ thể thông báo.

E.17.2. Yêu cầu đối với máy chủ

Khi lựa chọn một dịch vụ được giải xáo trộn, yêu cầu máy chủ xử lý tất cả các CA_descriptor xuất hiện trong cả vòng nhãn mô tả đầu tiên (Program Stream Loop) và vòng nhãn mô tả thứ hai (Elementary Stream Loop) của PMT. Nhiều CA_descriptor với CA_system_ID khác nhau có thể có trong một hoặc cả hai vòng.

Máy chủ phải truyền tất cả các CA_descriptor có trong PMT đến CICAM trong ca_pmt sử dụng cp chương trình tương ứng và/hoặc các vòng cp dòng thành phần, ngoại trừ máy chủ có thể tùy chọn loại bỏ bất kỳ CA_descriptor không phù hợp với bất kỳ CA_system_id được CICAM thông báo trong ca_info () APDU.

Máy chủ nên, không bắt buộc, duy trì thứ tự CA_descriptor và dòng thành phần giống nhau của PMT trong ca_pmt.

E.17.3. Yêu cầu đối với CICAM

CICAM phải bao gồm tất cả các CA_system_ID mà nó hỗ trợ trong ca_info () APDU khi có yêu cầu của máy chủ.

CICAM phải chắc chắn về sự có mặt của nhiều CA_descriptor có thể xuất hiện theo một thtự bất kỳ. CICAM phải chắc chắn về sự có mặt của các CA_descriptor phù hợp với bất kỳ (các) CA_system_id của CICAM và phải bỏ qua các CA_descriptor nếu chúng không được CICAM hỗ trợ.

CICAM phải chắc chắn về thứ tự của các dòng thành phần và phải có khả năng giải xáo trộn các dòng thành phần được CA hỗ trợ và thông báo một cách chính xác mà không phân biệt thứ tự của chúng trong ca_pmt.

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

E.18.1. Bản quy định kỹ thuật

En 50.221 [7], điều 8.4.1.1 quy định:

Khi máy chủ yêu cầu về các hồ sơ trên tất cả các kết nối truyền ti và trả lời hồ sơ đã nhận được thì máy chủ xây dựng một danh sách các tài nguyên sẵn có. Trường hợp có hai hoặc nhiều tài nguyên phù hợp trong cả lớp và loại thì máy chủ giữ một tài nguyên với số phiên bản cao nhất trong danh sách của nó.

E.18.2. Yêu cầu

Trong trường hợp máy chủ hỗ trợ nhiều phiên bản của cùng một tài nguyên thì số phiên bản cao nhất của tài nguyên chỉ được máy chủ thông báo. Các phiên bản thấp hơn của tài nguyên phải được máy chủ hỗ trợ nhưng không được thông báo trong profile_reply () APDU.

CICAM có thể yêu cầu một phiên bản thấp hơn của tài nguyên so với phiên bản được máy chủ thông báo, điều này được thảo luận trong điều E.19.

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

E.19.1. Bản quy định kỹ thuật

En 50.221 [7], điều 7.2.6.1 quy định:

Đối tượng này được mô-đun gửi đến máy chủ để yêu cầu mở một phiên giữa mô đun này và một tài nguyên được máy chủ hoặc mô-đun cung cấp. resource_identifier phải phù hợp với cả lớp và loại của tài nguyên mà máy chủ có trong danh sách các tài nguyên sẵn có. Nếu trường phiên bn của nhãn định danh tài nguyên được cung cấp là số không thì máy chủ sẽ sử dụng phiên bản hiện tại trong danh sách của nó. Nếu số phiên bản trong yêu cầu là nhỏ hơn hoặc bằng số phiên bản hiện tại trong danh sách của máy chủ thì phiên bản hiện tại được sử dụng. Nếu số phiên bn được yêu cầu cao hơn so với các phiên bn trong danh sách của máy chủ thì máy chủ sẽ từ chối yêu cầu với mã trả về phù hợp.

E.19.2. Sa đổi

Nội dung sửa đổi so với EN 50221 [7] như sau:

Đối tượng này được mô-đun gửi đến máy chủ để yêu cầu mở một phiên giữa mô đun này và một tài nguyên được máy chủ hoặc mô-đun cung cấp. resource_identifier phải phù hợp với cả lớp và loại của tài nguyên mà máy chủ có trong danh sách các tài nguyên sẵn có. Nếu trường phiên bản của nhãn định danh tài nguyên được cung cấp là số không thì máy chủ sẽ sử dụng phiên bản hiện tại trong danh sách của nó. Nếu số phiên bản trong yêu cầu là bằng với số phiên bản hiện tại trong danh sách của máy chủ thì phiên bản hiện tại được sử dụng. Nếu số phiên bản trong yêu cầu nh hơn so với số phiên bn hiện tại trong danh sách của máy chủ thì máy chủ phải sử dụng số phiên bản theo yêu cầu của CICAM. Nếu số phiên bản được yêu cầu cao hơn so với các phiên bản trong danh sách của máy chủ, sau đó máy chủ sẽ từ chối yêu cầu với mã tr v phù hợp.

Yêu cầu máy chủ phải luôn luôn hỗ trợ tất cả các phiên bản thp hơn của một tài nguyên được thông báo.

E.19.3. Khuyến ngh

CICAM không nên sử dụng trường phiên bản của nhãn định danh tài nguyên là số không và phải quy định số phiên bản cao nhất của tài nguyên được CICAM hỗ trợ.

CICAM không bao giờ được yêu cầu một số phiên bản mà nó không có khả năng hỗ trợ hoàn toàn và không được trả về số phiên bản được máy chủ thông báo, trừ khi nó được hỗ trợ hoàn toàn.

E.20. Cung cấp CA PMT

E.20.1. Giới thiệu

Việc máy chủ không gửi CA PMT khi thay đổi từng và mọi dịch vụ gây ra nhiều vấn đ đối với CICAM bao gồm:

1) PPT không được tính một cách chính xác (vì không có thông báo thay đổi dịch vụ),

2) Kiểm soát của cha mẹ không luôn luôn được thực thi khi truy nhập lại một dịch vụ được bảo vệ.

3) MMI ứng dụng không được khi tạo lại.

E.20.2. Bản quy định kỹ thuật

EN 50221 [7], điều 8.4.3.3 quy định:

Máy chủ có thquyết định việc gửi CA PMT cho tất cả các ứng dụng CA được kết nối hoặc ch đến các ứng dụng hỗ trợ giá trị CA_system_id giống như giá trị được cho trong CA_descriptor của dòng thành phần được lựa chọn (ES).

EN 50221 [7], điều 8.4.3.4 quy định:

Thiết bị thu gửi một CA PMT mới hoặc một danh sách mới của CA PMT đến ứng dụng này khi:

• người sử dụng chọn một chương trình khác

• lệnh 'dò kênh' lựa chọn một dịch vụ khác (xem 8.5.1.1)

• version_number thay đổi

• current_next_indicator thay đổi

E.20.3. Khuyến nghị đối với máy chủ

Máy chủ nên gửi một CA PMT mi khi thay đổi từng dịch vụ và khi thay đổi version_number hoặc current_next_indicator đến tất cả các ứng dụng CA được kết nối có hoạt động giải xáo trộn.

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

E.21.1. Bản quy định kỹ thuật

EN50221: 1997 [7], điều 8.4.3.4 quy định:

(Các) CA_descriptor ở cấp elementary_stream là hợp lệ chỉ đối với elementary_stream. Nếu, đối với một elementary_stream, (các) CA_descriptor tồn tại cấp chương trình và cấp elementary_stream thì chỉ (các) CA_descriptor cấp elementary_stream được xem xét.

ITU-T J.96: 2001 [39], điều 6.2.3, các chế độ 2 và 3 quy định:

Một CA_descriptor có thể có mặt trong PMT ở cấp chương trình, cho một ECM_pid đối với tất cả các thành phần của một chương trình. Các CA_descriptor bổ sung có thể có mặt tại cp độ thành phần. Trong trường hợp này, nó thay thế giá trị đã được quy định ở cấp chương trình, chỉ dành cho các thành phần liên quan.

E.21.2. Yêu cầu CICAM

Trong ca_pmt () APDU; các CA_descriptor sẵn có cp thành phần (ES) đối với một thành phần nht định có thể được CICAM giải xáo trộn thì bất kỳ các CA_descriptor cấp chương trình phải bị b qua đối với thành phn này.

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

E.22.1. Bản quy định kỹ thuật

EN-50221:1997 [7], điều 8.4.3 quy định:

Sau đó phiên này được giữ mở dành cho hoạt động định kỳ của giao thức liên kết với các đối tượng CA PMT và CA PMT Reply.

R206-001:1998 [24], điều 9.5.5.1 quy định:

Trong trường hợp lỗi lặp đi lặp lại, nó cũng có thể đóng phiên hỗ trợ CA và mở lại nó.

Nếu phiên dành cho tài nguyên hỗ trợ CA đóng, ứng dụng CA này nên cố gắng mở một phiên khác.

E.22.2. Yêu cầu đối với máy chủ

Máy chủ phải hỗ trợ việc đóng và mở lại phiên hỗ trợ CA.

E.22.3. Yêu cầu đối với CICAM

Nếu phiên hiện tại của tài nguyên hỗ trợ CA bị đóng thì CICAM phải cố gắng mở lại nó.

E.23. Các lệnh ca_pmt

E.23.1. Bản quy định kỹ thuật

EN50221 [7] liệt kê một số giá trị ca_pmt_cmd_id. Tác động của loại ca_pmt từ máy chủ được CICAM phân tích

E.23.2. Yêu cầu đối với CICAM

CICAM phải hỗ trợ tất cả các giá trị ca_pmt_cmd_id được liệt kê trong EN 50221 [7], điều 8.4.3.4. Khi CICAM nhận được một ca_pmt với ca_pmt_cmd_id được thiết lập là truy vấn đối với một chương trình hoặc dòng thành phần, CICAM phải gửi ca_pmt_reply đến máy chủ và không được bắt đầu giải xáo trộn và không được hiển thị bất kỳ MMI.

E.24. open_session_response

E.24.1. Bn quy đnh kỹ thuật

Máy chủ gửi một open_session_response () SPDU để trả lời một open_session_request () của CICAM. open_session_response () chứa một giá trị trạng thái theo tiêu chun EN 50221 [7], bảng 7.

E.24.2. Yêu cầu đối với CICAM

CICAM phải xử lý tất cả các giá trị trạng thái trong EN 50221 [7], bảng 7.

CICAM phải chắc chắn khi máy chủ tr về trạng thái "phiên không được mở, tài nguyên bận". Trong trường hợp này, CICAM nên thmở phiên cho đến khi máy chủ có thể đáp ứng yêu cầu này.

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

E.25.1. Bản quy định kỹ thuật

Tuân theo EN50221 [7], điều 8.6.2.3 và sửa đổi theo R206-001 [24], điều 9.8.5.

E.25.2. Yêu cầu đối với máy chủ

Máy chủ phải trả lời một display_control () APDU có các loại get_display_character_table_list (02) và get_input_character_table_list (03).

E.25.3. Khuyến nghị đối với máy chủ

Máy chủ nên trả lời bằng tất cả các mã ký tự được hồ sơ cơ bản của quốc gia hoặc khu vực hoặc mạng mà máy chủ hiện đang được cu hình yêu cầu. Máy chủ có thể tùy chọn bao gồm tt cả các bảng mã ký t khác được MMI cp cao hỗ trợ mà có thể không được cu hình hiện tại của máy chủ yêu cầu.

Trong trường hợp mạng chỉ yêu cầu bộ ký tự mặc định (theo ISO/IEC 6937) thì máy chủ phải trả lời yêu cầu display_control () APDU bằng một display_reply () APDU và vòng character_table_byte phải có độ dài bng không để chỉ ra rằng bộ ký tự mặc định được hỗ trợ. Ví dụ:

Quốc gia/Khu vực

character_table_byte

Các bảng ký tự

Pháp,Đức,...

{0x01}

ISO/IEC 6937 và ISO/IEC 8859-9

Vương quốc Anh

{}

Chỉ ISO/IEC 6937

Nordig

{0x01, 0x05, 0x10, 0x00, 0x01, 0x10, 0x00, 0x04, 0x10, 0x00, 0x0f}

ISO/IEC 6937, ISO/IEC 8859-9, ISO/IEC 8859-9, ISO/IEC 8859-1, ISO/IEC 8859-4, ISO/IEC 8859-15

 

Phụ lục F

(quy định)

Định nghĩa và xử lý mã lỗi

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

Bảng F.1 - Các mã lỗi ARC

Mã lỗi

Điều kiện lỗi

Lỗi phát hiện bởi

Hành động của máy chủ

Hành động của mô-đun Cl+

Din giải

00

Không

N/A

Không

Không

 

01

Mô đun phát hiện

CICAM

Không

CICAM chuyn sang chế độ pass-through (CHÚ THÍCH 1)

 

02

Máy chủ phát hiện

CICAM

 

- CICAM chuyển sang chế độ pass-through (CHÚ THÍCH 1)

- Một bản tin thông báo thu hi được hin thị.

 

03

SAC tht bại

CICAM/Host

 

- Nếu EMI>0 CICAM chuyn sang chế độ pass-through, nếu không chuyển qua chế độ DVB Cl.

- Một bản tin thông báo lỗi được hiển thị.

Các nhà khai thác dch vụ và CAS có thể chọn theo những điều kiện để gii mã khi vận hành chế độ DVB CI.

04

CCK tht bại

CICAM/Host

 

- Nếu EMI>0 CICAM chuyn sang chế độ pass-through, nếu không chuyển qua chế độ DVB Cl.

- Một bản tin thông báo lỗi được hiển thị.

Các nhà khai thác dịch vụ và CAS có thể chọn theo những điều kiện đgiải mã khi vận hành chế độ DVB Cl.

05

Cập nhật Firmware CICAM thất bại;

- Bootloader

CICAM

Không

Khuyến nghị:

- CICAM th lại ti v lần 2.

- Một bản tin thông báo lỗi được hiển th.

 

06

Cập nht Firmware CICAM tht bại;

- Lỗi v trí

CICAM

Không

Khuyến nghị:

- CICAM thử lại tải về lần 2.

- Một bản tin thông báo lỗi được hiển th.

 

07

Cập nhật Firmware CICAM tht bại;

• Lỗi ký hình ảnh

CICAM

Không

Khuyến nghị:

- CICAM th lại tải v ln 2.

- Một bản tin thông báo lỗi được hiển thị.

 

08

Xác thực tht bại

- Quá tải

CICAM

Không

- CICAM chuyn sang chế độ pass-through.

 

09

Xác thực tht bại

- Xác minh chữ ký tht bại

CICAM/Host

Máy chủ dừng CICAM

- CICAM chuyn sang chế độ pass-through.

 

10

Xác thực thất bại

- Xác minh khóa xác thực tht bại

CICAM/Host

Máy chủ dừng CICAM

- CICAM chuyn sang chế độ pass-through.

 

11

Xác thực thất bại

- Tính toán khóa tht bại

CICAM/Host

Máy chủ dừng CICAM

- CICAM chuyn sang chế độ pass-through.

 

12

Xác thực tht bại

- DH tht bại

CICAM/Host

Máy chủ dừng CICAM

- CICAM chuyn sang chế độ pass-through.

 

13

Giy chứng nhận CICAM không hợp lệ

- Sai cú pháp

Host

Máy chủ dừng CICAM

Không

 

14

Giấy chứng nhận CICAM không hợp lệ
- Hết hạn

Host

Máy chủ chuyn sang chế độ DVB- Cl (CHÚ THÍCH 2)

Không

 

15

Giấy chứng nhận CICAM không hợp l

- Xác thực chữ ký tht bại

Host

Máy chủ dừng CICAM

Không

 

16

Giy chng nhận máy chủ không hợp lệ

- Sai cú pháp

CICAM

Không

- CICAM chuyn sang chế độ Pass-through

- một bản tin phản hồi thông báo lỗi được hiển th

 

17

Giấy chng nhận máy chủ không hợp lệ

- Hết hạn

CICAM

Không

• CICAM chuyn sang chế độ DVB-CI (CHÚ THÍCH 3)

- một bản tin phản hồi thông báo lỗi được hiển thị.

 

18

Giấy chứng nhận máy chủ không hợp lệ

- Xác thực chữ ký thất bại

CICAM

Không

- CICAM chuyn sang chế độ Pass-through

- một bản tin phản hồi thông báo lỗi được hiển thị

 

19

Giy chứng nhận nhà khai thác dịch vụ không hợp lệ

- Sai cú pháp

CICAM

Không

- CICAM chuyển sang chế độ DVB-CI (CHÚ THÍCH 3)

- một bản tin phản hồi thông báo lỗi được hiển th.

 

20

Giy chứng nhận nhà khai thác dịch vụ không hợp lệ

- Hết hạn

CICAM

Không

- CICAM chuyn sang chế độ DVB-CI (CHÚ THÍCH 3)

- một bản tin phản hồi thông báo lỗi được hiển thị.

 

21

Giy chứng nhận nhà khai thác dịch vụ không hợp lệ

- Xác thực chữ ký tht bại

CICAM

Không

- CICAM chuyn sang chế độ DVB-CI (CHÚ THÍCH 3)

- một bản tin phản hồi thông báo lỗi được hiển thị.

 

22

Trình cập nhật các yêu cu của CICAM

CICAM

Không

- CICAM chuyn sang chế độ Pass-through

- một bản tin phản hồi thông báo lỗi được hiển thị

 

23 - 127

Dự phòng cho Cl Plus

CICAM

Không

- một bản tin phản hi thông báo lỗi được hiển thị

 

128 - 255

Dùng riêng cho nhà khai thác dch v

CICAM

Không

- một bản tin phản hồi thông báo li được hiển th

 

CHÚ THÍCH:

1: CICAM chuyển tiếp dòng truyền tải không b thay đổi và không giải xáo trộn bất kỳ dịch vụ (dịch vụ Cl Plus hoặc dịch vụ DVB-CI).

2: Máy chủ hoạt động như một máy chủ tuân th DVB-CI.

3: CICAM ch giải xáo trộn trong các dịch vụ không yêu cu được Cl Plus bo vệ (chế độ trở về DVB-CI)

 

Phụ lục G

(quy định)

Tối ưu PCMCIA

Lớp vật lý d