Trang 2/5 đầuđầu 1234 ... cuốicuối
kết quả từ 11 tới 20 trên 42
  1. #11
    Tham gia
    Nov 2007
    Nơi Cư Ngụ
    HVKTQS
    Bài viết
    1.715
    Thanks
    194
    Thanked 3.248 Times in 810 Posts

    Mặc định

    Trích Nguyên văn bởi KIRA Xem bài viết
    Xin chân thành cảm ơn những góp ý của bác nhat_kiem. Đúng là trong lĩnh vực viễn thông có quá nhiều mảng khác nhau. Không phải vấn đề nào cũng nhận được sự chú ý của nhiều người nhưng em sẽ không nản chí. Sẽ vẫn tiếp tục viết và cống hiến cho diễn đàn nói riêng và các bạn yêu thích viễn thông nói riêng những bài viết chất lượng nhất.
    Gambatte kudasai. ^^
    Kudasai KIRA!

  2. #12
    Tham gia
    Jun 2008
    Nơi Cư Ngụ
    học viện công nghệ bưu chính viễn thông
    Bài viết
    84
    Thanks
    9
    Thanked 116 Times in 24 Posts

    Mặc định

    @ thầy Bình: Em xin cảm ơn thầy đã động viên. Đợt vừa rồi em cũng hơi bận nên bây giờ mới tiếp tục được phần còn lại của bài viết.
    Phần hai của bài viết trình bày về những thách thức của bảo mật nhóm trong IP Multicast. Và đưa ra ba vấn đề cần phải giải quyết để cung cấp bảo mật truyền thông nhóm theo quan điểm của nhóm nghiên cứu SMuG IRTF và nhóm làm việc MSEC IETF:

    2.1 Multicast và những thách thức trong vấn đề bảo mật nhóm
    Với ưu điểm về tiết kiệm băng thông như Multicast, nó là nền tảng để triển khai các dịch vụ đa phương tiện như phân phối dữ liệu, các chương trình truyền hình theo yêu cầu, hội thảo đa phương tiện... Tuy nhiên, khi nhìn vào thực tế chúng ta thấy rằng sau rất nhiều các công trình nghiên cứu và phát triển các giao thức Multicast trong thập kỷ trước, việc triển khai các ứng dụng của Multicast vẫn rất chậm chạp. Nguyên nhân chính là do các dịch vụ Multicast thiếu hỗ trợ về quản lý lưu lượng, độ tin cậy và bảo mật.

    Bảo mật trong Multicast đưa ra cho ta những thách thức kỹ thuật thú vị. Các nhà thiết kế Multicast đưa ra cách sử dụng của nó để phân phối nội dung dữ liệu một cách đồng thời tới số lượng lớn các bên nhận. Nếu chỉ các bên nhận đó được cho phép nhìn thấy nội dung, nội dung dữ liệu phải được mã hóa. Nhưng một khóa mã hóa có thể làm thế nào để được phân phối hiệu quả tới nhiều bên nhận? Hơn nữa, một khóa cho dữ liệu mã hóa nên được thay đổi theo chu kỳ, vì chúng ta không chấp nhận mã hóa nhiều dữ liệu với chỉ cùng một khóa. Và nó có lẽ nên được thay đổi khi các thành viên của nhóm thay đổi. Giả thiết rằng các thành viên nhóm trả tiền để nhận nội dung như các kênh TV đặc biệt, khi một thành viên rời khỏi nhóm, nhóm không thể bắt thành viên đó quên khóa. Thêm nữa là nó muốn thay đổi khóa khi một thành viên mới gia nhập nhóm (để chúng không thể ghi lại nội dung mã hóa mà chúng không được quyền hoặc gia nhập trong một thời gian ngắn để tìm hiểu khóa sau đó chúng sẽ giải mã nội dung mà không được cho phép).

    Vấn đề khác trong bảo mật thông tin là bảo vệ tính sự toàn vẹn và nhận thực dữ liệu. Với một mẫu khóa bí mật, ai đó đang kiểm tra dữ liệu phải biết cùng một bí mật mà được sử dụng để tạo trường kiểm tra tính toàn vẹn. Với thông tin hai bên thì điều đó không phải là vấn đề. Nếu Alice đang gửi cái gì đó cho Bob, với một trường kiểm tra tính toàn vẹn đã được tạo ra từ một khóa mà chỉ hai bên chia sẻ, nếu trường kiểm tra tính toàn vẹn hợp lệ, BoB biết được rằng chỉ có Alice hay Bob có thể đã tạo ra bản tin. Nếu Bob biết nó không phải của anh ấy thì nó phải là của Alice.

    Tuy nhiên, nếu cùng một kiểu đó được sử dụng trong thông tin nhóm, nơi mà Alice đang gửi nội dung tới hàng nghìn bên nhận, mỗi bên trong số hàng nghìn bên nhận đó sẽ phải biết cùng một bí mật mà Alice sử dụng để tạo trường kiểm tra bí mật. Điều này có nghĩa là nội dung có thể đã bắt nguồn từ bất kỳ thành viên nào của nhóm. Do vậy, Alice phải tin tưởng tất cả thành viên nhóm đọc dữ liệu.

    Có ba vấn đề cần lưu tâm trong việc cung cấp các dịch vụ bảo mật Multicast. Đầu tiên, các bên gửi cần phải mã hóa và nhận thực dữ liệu Multicast. Đối với việc mã hóa, các thành viên nhóm yêu cầu một khóa chung giữa chúng. Thêm nữa, điều khiển truy nhập có thể được tiến hành bằng sự phân phối một khóa chung tới các thành viên nhóm, mà không cần tới sự thay đổi mô hình IPMulticast. Khi các thành viên nhóm thay đổi, khóa chung có thể cần thiết phải thay đổi và phân phối lại tới nhóm mới của các thành viên đã được nhận thực. Do đó sự phân phối khóa nhóm khả định cỡ và các kiểu chuyển khóa là một phần quan trọng của giải pháp bảo mật Multicast. Tiếp theo, các thành viên phải có khả năng kiểm tra dữ liệu được nhận đã thực sự được gửi bởi một thành viên đã được nhận thực hay không. Bởi vậy nhận thực nguồn gốc dữ liệu và mã hóa dữ liệu là một trong những vấn đề cần lưu tâm.

    Thêm nữa, những ứng dụng Multicast khác nhau- trong phạm vi từ việc thông tin đa người dùng tới phân phối dữ liệu từ một tới nhiều người dùng có những yêu cầu biến đổi đối với các hệ thống đầu cuối, truyền thông và bảo mật. Chính sách nhóm cho phép chủ nhóm hay nhà cung cấp nội dung chỉ rõ các yêu cầu cũng như trạng thái nhóm mong muốn được thay đổi trong môi trường hoạt động.
    Lần sửa cuối bởi KIRA; 10/11/2014 lúc 14:54

  3. The Following 3 Users Say Thank You to KIRA For This Useful Post:

    longpepe (27/03/2011), lotustila (22/07/2013), pvhung (23/02/2009)

  4. #13
    Tham gia
    Jun 2008
    Nơi Cư Ngụ
    học viện công nghệ bưu chính viễn thông
    Bài viết
    84
    Thanks
    9
    Thanked 116 Times in 24 Posts

    Mặc định

    2.2 Vấn đề 1: Nhận thực dữ liệu Multicast
    Vấn đề nhận thực dữ liệu Multicast bao gồm ba yếu tố: toàn vẹn dữ liệu, nhận thực, và không- từ chối.

    Bên nhận phải có khả năng xác định dữ liệu đã không bị chỉnh sửa bởi các thành viên khác của nhóm Multicast hay của các kẻ địch bên ngoài. Tính chất này được gọi là bảo vệ tính toàn vẹn.
    Các bên nhận cần phải có khả năng thiết lập nguồn của dữ liệu, ít nhất là cho chính chúng. Nói cách khác, ta cần nhận thực gốc dữ liệu.
    Một phiên bản mạnh hơn của các tính chất trên, được gọi là không- từ chối, cho phép bên thứ ba kiểm tra nguồn dữ liệu.

    Toàn vẹn dữ liệu và nhận thực dữ liệu liên quan chặt chẽ với nhau. Chú ý rằng nếu dữ liệu đã bị chỉnh sửa trong khi truyền dẫn, nguồn không còn còn là điểm bắt đầu của dữ liệu nữa. Tương tự, nếu một bên nhận có thể thiết lập nguồn của dữ liệu (ít nhất là cho chính nó), dữ liệu đã không bị chỉnh sửa trên đường đi. Do vậy toàn vẹn dữ liệu và nhận thực dữ liệu là phụ thuộc vào nhau. Không- từ chối bản chất là một phiên bản mạnh hơn của nhận thực dữ liệu. Nói cách khác, một giao thức hay cơ chế đảm bảo không từ chối thì cũng đảm bảo nhận thực.

    Hai cơ chế khác nhau thường được sử dụng cho nhận thực nguồn. Đầu tiên là sử dụng chữ ký số cho không- từ chối, và thứ hai là sử dụng MAC chỉ cho việc nhận thực. Phải nhắc lại rằng không- từ chối là dạng mạnh hơn của nhận thực. Tuy nhiên, trong khi MAC không thể cung cấp không- từ chối thì chúng lại hiệu quả hơn khi so sánh với chữ ký số. Đăng ký số mỗi gói của luồng dữ liệu đắt đỏ ghê gớm (cả việc tính toán cùng với việc đảm bảo thông tin tiêu đề cho mỗi gói).

    Trong truyền thông Unicast, MAC hỗ trợ nhận thực dữ liệu như sau: Trong thông tin ngang hàng, Alice và Bob cùng giữ một khóa bí mật để nhận thực. Alice sử dụng khóa và hàm một chiều để tính hàm băm khóa của bản tin và gửi bản tin cùng với MAC tới bên nhận. Bob lặp lại thủ tục để tính MAC, và so sánh nó với MAC nhận được. Nếu các MAC tương ứng, Bob biết được rằng bản tin đã không bị chỉnh sửa trên đường đi. Anh ấy cũng biết được rằng anh ấy không gửi bản tin và do vậy Alice phải gửi nó, giả thiết rằng khóa nhận thực không bị tổn hại. Tuy nhiên, một bên thứ ba không thể kiểm tra bản tin đã được gửi bởi Alice hay Bob. Do vậy, MAC không thể cung cấp không- từ chối.

    Chúng ta có thể sử dụng MAC cho các phiên truyền thông nhóm nhận thực bằng những thủ tục tương tự như ở trên, nhưng với cấp độ giảm hơn về bảo mật. Chú ý tới nhóm, bao gồm Alice, Bob và Cindy, giữ một khóa nhận thực. Alice có thể sử dụng một MAC để nhận thực bản tin gửi tới Bob và Cindy. Bob (hay Cindy) không biết bản tin đã được gửi hay chỉnh sửa lần cuối bởi Alice hay Cindy (hay Bob). Thông thường, các thành viên nhóm có thể chỉ kiểm tra được các đối tượng không phải thành viên, người mà không giữ khóa nhận thực nhóm thì không thay đổi được dữ liệu trong khi truyền dẫn. Tính chất này đảm bảo chỉ bản tin được gửi hay sửa đổi bởi một thành viên của nhóm và được gọi là nhận thực nhóm.

    Nhận thực nguồn có thể thực hiện được bằng cách sử dụng chữ ký số. Bên gửi chia nhỏ dữ liệu thành từng khối. Với mỗi khối, nó tính toán một giá trị hash, đánh dấu hash và gửi chữ ký đi với khối dữ liệu. Khi kích thước mỗi khối tăng, bên gửi sử dụng ít chữ ký số hơn và các thành viên sử dụng kiểm tra chữ ký ít hơn. Tuy nhiên, một thành viên cần nhận một khối dữ liệu đầy đủ trước khi kiểm tra tính nhận thực của nó. Đối với các khối kích thước nhỏ hơn, số lượng chữ ký và kiểm tra tăng lên. Ưu điểm là các thành viên không cần đợi lâu trước khi kiểm tra và sử dụng một khối dữ liệu. Tuy nhiên, trong thực tế, đánh dấu mỗi gói trong luồng thời gian thực tốc độ cao là không khả thi. Sử dụng các chữ ký một lần có chút ít hiệu quả hơn so với đánh dấu mỗi gói. Nhưng chữ ký một lần yêu cầu số lượng lớn tính toán hash và không thể điều khiển tổn thất gói.

    Trong phạm vi bài viết trên diễn đàn, tôi sẽ chỉ nêu hai phương pháp cho nhận thực nguồn sử dụng chữ ký số được áp dụng cho dữ liệu kiểu khối và dữ liệu kiểu luồng:

    2.2.1 Hashing khối
    Có hai kiểu hashing khối thường được sử dụng là Star hashingTree hashing:

    Star hashing
    Bên gửi chia một khối dữ liệu thành m gói. Nó đánh dấu một hash của khối (block hash), và rồi làm giảm giá của chữ ký thông qua m gói. Để nhận thực từng gói riêng rẽ, nó tính toán các hash h1, h2,…,hm của m gói. Hash khối, h, là hàm hash(h1, h2,…,hm), trong đó, hi = hash(Pi), Pi là gói thứ i. Với mỗi gói, bên gửi bao gồm hash khối và các hash của tất cả các gói trong khối. Nó cũng gửi vị trí tương đối của gói trong khối.

    Hình dưới đây minh hoạ kỹ thuật star hashing. Các nhánh là các hash của các gói, và gốc là hash khối. Trong hình cũng mô tả mối quan hệ giữa các hash của các gói và hash khối; đó là: hash khối phụ thuộc vào tất cả các hash nhánh.
    [URL=
    Lần sửa cuối bởi KIRA; 10/11/2014 lúc 14:54

  5. The Following 4 Users Say Thank You to KIRA For This Useful Post:

    sipvn (13/04/2009), tienducvtc (01/08/2012), trandat (05/11/2008), vutuanmta (28/11/2012)

  6. #14
    Tham gia
    Aug 2008
    Nơi Cư Ngụ
    nhàn rỗi
    Bài viết
    136
    Thanks
    80
    Thanked 70 Times in 28 Posts

    Mặc định

    A.K rất thích những bài chuyên môn bài bản như thế.
    NHững bài viết như vậy có giá trị bất chấp thời gian.

    Một ngày nào đó sẽ quay lại tìm hiểu và theo gót KIRA đề tài này, như đã từng làm với VOIP vậy
    (Bây giờ bận túi bụi với chương trình học, chỉ rảo diễn đàn cập nhật thông tin thôi ... )


    Chân thành cảm ơn KIRA, cảm ơn cách đóng góp của KIRA cho diễn đàn.
    Think Different

  7. The Following User Says Thank You to A.K For This Useful Post:

    KIRA (07/11/2008)

  8. #15
    Tham gia
    Apr 2008
    Nơi Cư Ngụ
    VNPT
    Bài viết
    5
    Thanks
    2
    Thanked 4 Times in 2 Posts

    Mặc định

    Trích Nguyên văn bởi KIRA Xem bài viết
    Sao không có bạn nào vào discuss về topic này thế nhỉ. Tôi nghĩ chúng ta nên có những bài viết về chuyên môn sâu sắc một chút nên mới kì công chuẩn bị bài, vậy mà không ai hưởng ứng lắm nhỉ. Có nên viết tiếp về phần group security in IPMulticast nữa không đây?
    Cảm ơn KIRA đã bỏ công sức viết những chuyên đề sâu như thế này, không phải ai cũng làm được ( tôi chưa làm được).

    Nhưng cho mình hỏi một chút, KIRA nghiên cứu được gì qua Project này ? Những thông tin trong phần đã gửi lên, nói thật là đã có rất nhiều trên Internet, đọc hoài cũng chưa có gì mới. Một số phần như mospf thì mang tính lý thuyết là nhiều. Trong thực tế triển khai, tôi chắc chắn không dùng.

    Nếu có thời gian, KIRA thử tìm hiểu multicast trong MPLS xem sao. Tôi nghĩ sẽ thực tế hơn, hấp dẫn hơn là chỉ dừng ở mức tìm hiểu cơ bản về Multicast.
    Một lần nữa cảm ơn KIRA.

  9. #16
    Tham gia
    Jan 2009
    Nơi Cư Ngụ
    Ha noi
    Bài viết
    3
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Mặc định Iptv

    Mình đang tìm hiểu về IPTV và nó liên quan rất nhiều đến IP Multicast > Mình thấy bạn đã bỏ ra khá nhiều thời gian để tìm hiểu về vấn đề này. Rất mong bạn có thể chia sẻ cho mình những tìm hiểu của bạn. Xin cảm ơn.
    Ah, để có thể trao đổi được nhiều hơn xin bạn cho mình sdt hoạc email nhé .Mail của mình strkhoi@yahoo.com.
    Xin cảm ơn. Mong reply của bạn.

  10. #17
    Tham gia
    Jun 2008
    Nơi Cư Ngụ
    học viện công nghệ bưu chính viễn thông
    Bài viết
    84
    Thanks
    9
    Thanked 116 Times in 24 Posts

    Mặc định

    Trích Nguyên văn bởi Tumax Xem bài viết
    Cảm ơn KIRA đã bỏ công sức viết những chuyên đề sâu như thế này, không phải ai cũng làm được ( tôi chưa làm được).

    Nhưng cho mình hỏi một chút, KIRA nghiên cứu được gì qua Project này ? Những thông tin trong phần đã gửi lên, nói thật là đã có rất nhiều trên Internet, đọc hoài cũng chưa có gì mới. Một số phần như mospf thì mang tính lý thuyết là nhiều. Trong thực tế triển khai, tôi chắc chắn không dùng.

    Nếu có thời gian, KIRA thử tìm hiểu multicast trong MPLS xem sao. Tôi nghĩ sẽ thực tế hơn, hấp dẫn hơn là chỉ dừng ở mức tìm hiểu cơ bản về Multicast.
    Một lần nữa cảm ơn KIRA.
    Chắc anh chưa đọc hết bài của em. Thật ra vấn đề security là vấn đề khá mới, anh đã đọc được ở đâu trên Internet có thể cho em biết, em cũng không cho bài viết chỉ dừng lại ở mức cơ bản đâu ạ. Có chăng chỉ là phần đầu giới thiệu một cách tổng quát nhất thôi, cái này không thể thiếu được bởi có nhiều bạn đọc chưa biết về IPMulticast.
    Cảm ơn sự quan tâm của anh TuMax.

    @strkhoi: IPTV cũng là một lĩnh vực em rất thích và cũng liên quan trực tiếp đến IPMulticast. Rất vui được thảo luận, trao đổi thêm nhiều với anh.
    Rất lâu rồi mới trở lại diễn đàn, mình sẽ tiếp tục phần còn dang dở của bài viết. Xin cảm ơn rất cả các bạn đã quan tâm.
    Lần sửa cuối bởi KIRA; 10/11/2014 lúc 14:52

  11. The Following User Says Thank You to KIRA For This Useful Post:

    dauphongduong (03/03/2009)

  12. #18
    Tham gia
    Oct 2008
    Nơi Cư Ngụ
    cổng làng
    Bài viết
    12
    Thanks
    3
    Thanked 0 Times in 0 Posts

    Mặc định

    BÁC KIRA ạh!
    Em đang quan tâm đến vấn đề điều khiển tắc nghẽn trong Multicast!
    Bác có thể viết giúp em hiểu hơn không?
    Hoặc cho em xint ai liệu cũng được!
    Lần sửa cuối bởi moonilu; 10/11/2014 lúc 16:05

  13. #19
    Tham gia
    Feb 2009
    Nơi Cư Ngụ
    qn
    Bài viết
    15
    Thanks
    0
    Thanked 2 Times in 1 Post

    Mặc định

    bac KIRA.Em thấy bài viết của bác rất hay và thú vị.bác làm ơn gửi cho em để em nghiên cứu làm đề tài tốt nghiệp được không ạ.cám ơn bác nhiều.bác gửi cho em theo địa chỉ:leluongvy@gmail.com

  14. #20
    Tham gia
    Mar 2008
    Nơi Cư Ngụ
    HPG
    Bài viết
    150
    Thanks
    68
    Thanked 86 Times in 36 Posts

    Mặc định

    Em cũng tìm hiểu IPTV, tuy nhiên đọc cái này mới hiểu qua 1 tí về lý thuyết cơ bản, phần sau em đọc thì mù tịt, trước học hành chểnh mảng mất hết gốc gác.
    Đợi từ từ nghiên cứu dần. Thanks!

Trang 2/5 đầuđầu 1234 ... cuốicuối

Quyền Sử Dụng Ở Diễn Ðàn

  • Bạn không thể gửi chủ đề mới
  • Bạn không thể gửi trả lời
  • Bạn không thể gửi file đính kèm
  • Bạn không thể sửa bài viết của mình
  •