กรอบงาน CAS

เฟรมเวิร์กระบบการเข้าถึงแบบมีเงื่อนไขของสื่อ (Media CAS) มอบ API มาตรฐานเพื่อเปิดใช้งานบริการการเข้าถึงแบบมีเงื่อนไข (CA) บนฮาร์ดแวร์ทีวีดิจิทัลหลายประเภท รวมถึงเคเบิลดิจิทัล ดาวเทียม ระบบภาคพื้นดิน และระบบ IPTV เฟรมเวิร์กนี้ทำงานร่วมกับ เฟรมเวิร์กอินพุต Android TV และ เฟรมเวิร์ก Android TV Tuner โดยจัดเตรียม Java API ที่เรียกใช้จากแอป TV Input Service (TIS)

วัตถุประสงค์หลักของ Media CAS มีดังนี้

  • จัดเตรียม Java API สาธารณะและเฟรมเวิร์กปลั๊กอินเนทิฟที่นักพัฒนาบุคคลที่สามและ OEM สามารถใช้เพื่อรองรับ CAS สำหรับการออกอากาศทีวีใน Android
  • จัดเตรียมเฟรมเวิร์ก CAS ภายใน Android ที่ช่วยให้ ATV OEM สามารถทำงานร่วมกับผู้จำหน่าย CAS หลากหลายรายในลักษณะที่สอดคล้องกัน
  • สนับสนุนผู้จำหน่าย CAS บุคคลที่สามหลายรายโดยใช้ปลั๊กอินดั้งเดิม ปลั๊กอิน CAS อาจใช้โปรโตคอลเครือข่ายเฉพาะของผู้จำหน่าย ข้อความการจัดการการให้สิทธิ์ (EMM)/รูปแบบข้อความควบคุมการให้สิทธิ์ (ECM) และตัวถอดรหัส
  • รองรับความปลอดภัยของฮาร์ดแวร์ เช่น บันไดกุญแจ
  • รองรับสภาพแวดล้อมการดำเนินการที่เชื่อถือได้ (TEE) เช่น TrustZone

การกำหนดค่าที่รองรับ

การกำหนดค่าจูนเนอร์ฮาร์ดแวร์

หากฮาร์ดแวร์มีหน้าที่รับผิดชอบในการดีมัลติเพล็กซ์และการถอดรหัสข้อมูลสตรีมการขนส่ง MPEG เฟรม เวิร์กจูนเนอร์ จะให้ข้อมูลข้อมูลเฉพาะโปรแกรมการเข้าถึงแบบมีเงื่อนไข (PSI) แก่แอป TIS เพื่อเชื่อมต่อกับเครื่องรับสัญญาณทีวีแบบฮาร์ดแวร์

ข้อมูล PSI การเข้าถึงแบบมีเงื่อนไขประกอบด้วยตัวอธิบาย CA, ECM และ EMM โครงสร้างเหล่านี้ช่วยให้ปลั๊กอิน CAS สามารถรับคีย์ที่จำเป็นในการถอดรหัสสตรีมเนื้อหา

ไดอะแกรมของการกำหนดค่าจูนเนอร์ฮาร์ดแวร์

รูปที่ 1. การกำหนดค่าจูนเนอร์ฮาร์ดแวร์

การกำหนดค่าฮาร์ดแวร์อาจมีเลเยอร์ TEE เช่น TrustZone ซึ่งแสดงในรูปที่ 1 หากไม่มีเลเยอร์ TEE ปลั๊กอินไคลเอ็นต์ CAS จะสามารถสื่อสารกับบริการแลดเดอร์คีย์ฮาร์ดแวร์ที่แพลตฟอร์มจัดเตรียมไว้ให้ เนื่องจากรูปแบบเฉพาะของผู้จำหน่ายของอินเทอร์เฟซเหล่านี้ Media CAS จึงไม่ได้สร้างมาตรฐานให้กับอินเทอร์เฟซเหล่านั้น

การกำหนดค่าซอฟต์แวร์

ก่อน Android 11 เฟรมเวิร์ก Media CAS ยังคงสามารถใช้เพื่อประมวลผลเนื้อหาที่ใช้ซอฟต์แวร์ เช่น IPTV จาก IP มัลติคาสต์/ยูนิคาสต์ แอป TIS มีหน้าที่รับผิดชอบในการสร้างอินสแตนซ์และจัดเตรียมออบเจ็กต์ Media CAS Java อย่างเหมาะสม

แอปอาจใช้ MediaExtractor หรือตัวแยกวิเคราะห์ MPEG2-TS อื่นๆ เพื่อดึงข้อมูล PSI ที่เกี่ยวข้องกับ CA เช่น ตัวอธิบาย CA, ECM และ EMM หากแอปใช้เฟรมเวิร์ก MediaExtractor แอปจะสามารถมอบหมายการจัดการเซสชัน CAS เช่น การเปิดเซสชันและการประมวลผล EMM/ECM ให้กับเฟรมเวิร์ก MediaExtractor ได้ จากนั้น MediaExtractor จะกำหนดค่าเซสชัน CAS โดยใช้ Native API โดยตรง

มิฉะนั้น แอปจะรับผิดชอบในการแยกข้อมูล PSI ที่เกี่ยวข้องกับ CA และกำหนดค่าเซสชัน CAS โดยใช้ Media CAS Java API (เช่น เมื่อแอปใช้ตัวแยกวิเคราะห์ MPEG2-TS ของตัวเอง)

แผนผังการกำหนดค่าจูนเนอร์

รูปที่ 2 อินพุต IPTV, CAS และการกำหนดค่าตัวถอดรหัสโดยใช้เฟรมเวิร์ก MediaExtractor

ในสถานการณ์จำลองตัวแยกซอฟต์แวร์ ตัวแยกข้อมูลต้องใช้ออบเจ็กต์ตัวถอดรหัสที่ใช้ซอฟต์แวร์หรือฮาร์ดแวร์สำหรับแต่ละแทร็กที่มีสัญญาณรบกวน ไม่ว่าแทร็กนั้นจะต้องใช้ตัวถอดรหัสที่ปลอดภัยหรือไม่ก็ตาม นี่เป็นเพราะสิ่งต่อไปนี้

  • หากแทร็กไม่ต้องการการถอดรหัสที่ปลอดภัย ตัวแยกสัญญาณจะถอดรหัสหน่วยการเข้าถึงเพื่อล้างบัฟเฟอร์ และแยกตัวอย่างราวกับว่ามาจากสตรีมที่ชัดเจน วิธีนี้ทำให้ MediaCodec ไม่จำเป็นต้องมีส่วนร่วมในการถอดรหัส
  • หากแทร็กต้องการการถอดรหัสที่ปลอดภัย ตัวแยกสัญญาณอาจยังต้องใช้ตัวถอดรหัส สิ่งนี้เกิดขึ้นเมื่อสตรีมการขนส่งถูกสัญญาณรบกวนที่ระดับแพ็กเก็ตการขนส่ง โดยที่ส่วนหัวของ packetized elementary stream (PES) ถูกสัญญาณรบกวน เครื่องมือแยกข้อมูลจำเป็นต้องเข้าถึงส่วนหัว PES เพื่อดาวน์สตรีมข้อมูลบางอย่าง (เช่น การประทับเวลาการนำเสนอ)

    ตัวแยกจะไม่ใช้ตัวถอดรหัสหากสตรีมการขนส่งถูกรบกวนที่ระดับแพ็กเก็ต PES โดยที่ส่วนหัว PES จะถูกปล่อยให้ว่าง อย่างไรก็ตาม ไม่สามารถยืนยันได้ว่าการแย่งชิงจะเกิดขึ้นเมื่อใดจนกว่าแพ็กเก็ตที่มีสัญญาณรบกวนจริงจะมาถึง เพื่อความง่าย สมมติว่ามีการใช้ Descrambler หากแทร็กถูกกำหนดให้มีสัญญาณรบกวนตามตารางการแม็ปโปรแกรม (PMT)

ข้อจำกัดของการกำหนดค่าซอฟต์แวร์

เมื่อแทร็กต้องการการถอดรหัสที่ปลอดภัย ตัวถอดรหัสจะต้องระมัดระวังเมื่อปล่อยให้การดำเนินการถอดรหัสเป็นบัฟเฟอร์ที่ชัดเจน เนื่องจากจำเป็นต้องมีการถอดรหัสเสียงที่ไม่ปลอดภัย หากการถอดรหัสวิดีโอต้องใช้ตัวถอดรหัสที่ปลอดภัย ก็ควรมีสัญญาณรบกวนในเซสชันที่แตกต่างจากเสียง ECM สำหรับเซสชันจะต้องส่งสัญญาณไปยังปลั๊กอินว่าจำเป็นต้องมีตัวถอดรหัสที่ปลอดภัย

หรืออีกทางหนึ่ง ปลั๊กอินจะต้องสามารถผูกคีย์กับนโยบายความปลอดภัยได้อย่างน่าเชื่อถือ มิฉะนั้น แอปจะสามารถรับเฟรมวิดีโอได้อย่างง่ายดายด้วยตัวถอดรหัสเสียง

แม้ว่าเซสชันจะต้องการตัวถอดรหัสที่ปลอดภัย ก็อาจถูกขอให้ส่งออกข้อมูลจำนวนเล็กน้อยเพื่อล้างบัฟเฟอร์โดยตัวแยกเพื่อประมวลผลส่วนหัว PES เพื่อป้องกันไม่ให้แอปที่เป็นอันตรายทำให้ปลั๊กอินส่งคืนหน่วยการเข้าถึงทั้งหมด ปลั๊กอินจำเป็นต้องแยกวิเคราะห์เพย์โหลดการขนส่งเพื่อให้แน่ใจว่าเพย์โหลดเริ่มต้นด้วยส่วนหัว PES ของประเภทสตรีมที่เหมาะสม มิฉะนั้นปลั๊กอินควรปฏิเสธคำขอ

ลำดับการปรับแต่ง CA

เมื่อปรับช่องสัญญาณใหม่ โมดูล TIS จะลงทะเบียนเพื่อรับตัวอธิบาย CA, ECM และ EMM จากเฟรมเวิร์ก PSI Tuner ตัวอธิบาย CA มีรหัสระบบ CA ซึ่งระบุผู้จัดจำหน่าย CA เฉพาะและข้อมูลเฉพาะผู้ขายอื่นๆ โดยไม่ซ้ำกัน TIS สอบถาม Media CAS เพื่อดูว่ามีปลั๊กอิน CAS ที่สามารถจัดการ CA descriptor ได้หรือไม่

แผนภาพการปรับเนื้อหา CAS

รูปที่ 3 การปรับแต่งเนื้อหา CAS

หากรหัสระบบ CA ได้รับการสนับสนุน อินสแตนซ์ของ Media CAS จะถูกสร้างขึ้น และข้อมูลส่วนตัวของผู้จัดจำหน่ายจากตัวอธิบาย CA จะถูกจัดเตรียมให้กับปลั๊กอิน จากนั้น เซสชันใหม่จะเปิดขึ้นใน Media CAS เพื่อจัดการสตรีมเสียงและวิดีโอ เซสชันที่เพิ่งเปิดใหม่จะได้รับ ECM และ EMM สำหรับปลั๊กอิน

ตัวอย่างโฟลว์ปลั๊กอิน CAS

TIS ส่ง ECM ไปยังปลั๊กอิน CAS โดยใช้ Media CAS API ECM มีคำควบคุมที่เข้ารหัส ซึ่งจำเป็นต้องถอดรหัสโดยใช้ข้อมูลจาก EMM ปลั๊กอิน CAS กำหนดวิธีการรับ EMM สำหรับสินทรัพย์โดยอิงตามข้อมูลเฉพาะของผู้ขายในตัวอธิบาย CA ซึ่งได้มาจากเมธอด setPrivateData()

EMM อาจถูกจัดส่งเป็นแบนด์ในสตรีมเนื้อหาหรือนอกแบนด์โดยใช้คำขอเครือข่ายที่เริ่มต้นโดยปลั๊กอิน CA TIS ใช้เมธอด processEMM() เพื่อส่ง EMM ในย่านความถี่ไปยังปลั๊กอิน CA

หากจำเป็นต้องมีคำขอเครือข่ายเพื่อรับ EMM ปลั๊กอิน CA จะรับผิดชอบในการดำเนินการธุรกรรมเครือข่ายกับเซิร์ฟเวอร์ใบอนุญาต

แผนภาพของ CAS ตัวอย่าง

รูปที่ 4 ตัวอย่างปลั๊กอิน CAS สำหรับการประมวลผล EMM และ ECM

เมื่อได้รับ EMM ปลั๊กอิน CA จะแยกวิเคราะห์เพื่อรับคีย์ที่เข้ารหัสเพื่อถอดรหัสคำควบคุม คีย์ EMM ที่เข้ารหัสและคำควบคุมที่เข้ารหัสอาจถูกโหลดลงในบันไดคีย์หรือสภาพแวดล้อมที่เชื่อถือได้เพื่อทำการถอดรหัสคำควบคุมและถอดรหัสสตรีมเนื้อหาในภายหลัง

สื่อ CAS Java API

Media CAS Java API มีวิธีการดังต่อไปนี้

  • แสดงรายการปลั๊กอิน CA ที่มีอยู่ทั้งหมดบนอุปกรณ์

    class MediaCas.PluginDescriptor {
      public String getName();
      public int getSystemId();
    }
    static PluginDescriptor[] enumeratePlugins();
    
  • สร้างอินสแตนซ์ Media CAS สำหรับระบบ CA ที่ระบุ ซึ่งหมายความว่ากรอบงาน Media CAS สามารถจัดการระบบ CAS หลายระบบพร้อมกันได้

    MediaCas(int CA_system_id);
    MediaCas(@NonNull Context context, int casSystemId,
             @Nullable String tvInputServiceSessionId,
             @PriorityHintUseCaseType int priorityHint);
    
  • ลงทะเบียน Listener เหตุการณ์และอนุญาตให้แอประบุตัวจัดการที่ใช้ Looper

    interface MediaCas.EventListener {
      void onEvent(MediaCas, int event, int arg, byte[] data);
      void onSessionEvent(@NonNull MediaCas mediaCas, @NonNull Session session, int event, int arg, @Nullable byte[] data);
      void onPluginStatusUpdate(@NonNull MediaCas mediaCas, @PluginStatus int status, int arg);
      void onResourceLost(@NonNull MediaCas mediaCas);
    }
    void setEventListener(MediaCas.EventListener listener, Handler handler);
    
  • ส่งข้อมูลส่วนตัวสำหรับระบบ CA ข้อมูลส่วนตัวอาจมาจากตัวอธิบาย CA, ตารางการเข้าถึงแบบมีเงื่อนไข หรือแหล่งที่มานอกแบนด์ สิ่งนี้ไม่เกี่ยวข้องกับเซสชันใดเซสชันหนึ่ง

    void setPrivateData(@NonNull byte[] data);
    
  • ประมวลผลแพ็กเก็ต EMM

    void processEmm(@NonNull byte[] data, int offset, int length);
    
  • ส่งเหตุการณ์ไปยังระบบ CA รูปแบบของกิจกรรมมีความเฉพาะเจาะจงกับแบบแผนและไม่ชัดเจนสำหรับกรอบงาน

    void sendEvent(int event, int arg, @Nullable byte[] data);
    
  • เริ่มต้นการดำเนินการจัดเตรียมประเภทที่ระบุสำหรับระบบ CA เมื่ออุปกรณ์สมัครใช้บริการเพย์ทีวีเป็นครั้งแรก อุปกรณ์นั้นจะต้องได้รับการจัดเตรียมให้กับเซิร์ฟเวอร์ CAS ก่อน จัดเตรียมชุดพารามิเตอร์ที่เกี่ยวข้องให้กับอุปกรณ์เพื่อการจัดเตรียม

    void provision(String provisionString);
    
  • ทริกเกอร์การรีเฟรชการให้สิทธิ์ เมื่อผู้ใช้สมัครรับข้อมูลช่องทางใหม่ (เช่น โดยการตอบสนองต่อโฆษณาหรือโดยการเพิ่มช่องทางในคู่มือโปรแกรมอิเล็กทรอนิกส์ (EPG)) แอปควรจะสามารถบอกไคลเอ็นต์ CA ให้รีเฟรชคีย์การให้สิทธิ์ได้

    void refreshEntitlements(int refreshType);
    
  • ปิดวัตถุสื่อ CAS

    void close();
    
  • เปิดเซสชัน

    Session openSession();
    Session openSession(@SessionUsage int sessionUsage, @ScramblingMode int scramblingMode);
    
  • ปิดเซสชันที่เปิดไว้ก่อนหน้านี้

    void Session#close();
    
  • จัดเตรียมข้อมูลส่วนตัวของ CA จากตัวอธิบาย CA ใน PMT ซึ่งอาจมาจากข้อมูลโปรแกรมหรือส่วนข้อมูล ES ไปยังเซสชัน CAS

    void Session#setPrivateData(@NonNull byte[] sessionId, @NonNull byte[] data);
    
  • ประมวลผลแพ็กเก็ต ECM สำหรับเซสชัน

    void Session#processEcm(@NonNull byte[] data, int offset, int length);
    
  • รับรหัสเซสชัน

    byte[] Session#getSessionId();
    
  • ส่งเหตุการณ์เซสชันไปยังระบบ CA รูปแบบของกิจกรรมมีความเฉพาะเจาะจงกับแบบแผนและไม่ชัดเจนสำหรับกรอบงาน

    void Session#sendSessionEvent(int event, int arg, @Nullable byte[] data);